View E-110_1947746.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

r14004.a ethernet-110 core technical manual
ii document number db14-000014-01, first edition (november 1997) this document describes lsi logic corporations ethernet-110 core and will remain the of?cial reference source for all revisions/releases of this product until rescinded by an update. to receive product literature, call us at 1.800.574.4286 (u.s. and canada); +32.11.300.531 (europe); 408.433.7700 (outside u.s., canada, and europe) and ask for department jds; or visit us at http://www.lsilogic.com. lsi logic corporation reserves the right to make changes to any products herein at any time without notice. lsi logic does not assume any responsibility or liability arising out of the application or use of any product described herein, except as expressly agreed to in writing by lsi logic; nor does the purchase or use of a product from lsi logic convey a license under any patent rights, copyrights, trademark rights, or any other of the intellectual property rights of lsi logic or third parties. copyright ? 1996, 1997 by lsi logic corporation. all rights reserved. trademark acknowledgment lsi logic logo design, coreware, and modular design environment are registered trademarks and c-mde, self-embedding, and right-first-time are trademarks of lsi logic corporation. all other brand and product names may be trademarks of their respective companies.
contents iii contents preface chapter 1 introduction 1.1 coreware ? program 1-1 1.2 fast ethernet (100 mbit/s) 1-2 1.2.1 fast ethernet overview 1-2 1.2.2 fast ethernet features 1-4 1.2.3 E-110 mac core and the osi model 1-6 1.2.4 fast ethernet hubs 1-7 1.2.5 fast ethernet network interface cards 1-10 1.3 E-110 core 1-11 1.4 E-110 mac core 1-13 1.4.1 mac core host system connection 1-13 1.4.2 mac multiple channel operation 1-17 1.4.3 mac external interfaces 1-18 1.4.4 mac mii 1-20 1.4.5 mac backoff operation 1-21 1.4.6 mac backpressure feature 1-22 1.5 mac control module core 1-22 1.6 miim core 1-23 chapter 2 signal descriptions 2.1 mac core signals 2-1 2.1.1 transmit function to host signals 2-3 2.1.2 receive function to host signals 2-5 2.1.3 mac control module signals (optional) 2-7 2.1.4 mii to phy signals 2-10 2.1.5 host control signals 2-14 2.1.6 statistics vector to host signals 2-21
iv contents 2.1.7 random number generator to host signals 2-27 2.1.8 scan test signals 2-27 2.2 mac control module signals 2-28 2.2.1 mac control module to E-110 core signals 2-29 2.2.2 mac control module to phy signals 2-31 2.2.3 mac control module to host signals 2-32 2.3 miim core signals 2-35 2.3.1 miim core to host signals 2-35 2.3.2 miim core to phy signals 2-39 chapter 3 core descriptions 3.1 clock operation 3-1 3.1.1 mtxc and mrxc 3-1 3.1.2 hclk 3-3 3.1.3 mdc 3-3 3.2 E-110 core operation 3-3 3.2.1 mac core operation 3-5 3.2.2 mac control module core operation 3-17 3.2.3 miim core operation 3-18 chapter 4 functional timing 4.1 mac functional timing 4-1 4.1.1 mac receive packet timing 4-1 4.1.2 mac transmit packet timing 4-4 4.2 miim core functional timing 4-6 4.2.1 miim write operation 4-7 4.2.2 mac miim read operation 4-8 4.3 transmit collision functional timing 4-9 chapter 5 speci?cations 5.1 derivation of ac timing and loading 5-1 5.2 mac core ac timing 5-2 5.3 mac core pin summary 5-4 5.4 mac control module core ac timing 5-6 5.5 mac control module core pin summary 5-8 5.6 miim core ac timing 5-10 5.7 miim core pin summary 5-11
contents v appendix a glossary customer feedback figures 1.1 100base-t media speci?cations 1-6 1.2 E-110 mac relationship to the osi model 1-7 1.3 hub examples 1-8 1.4 switched hub example 1-10 1.5 network interface card block diagram 1-11 1.6 E-110 asic environment 1-12 1.7 E-110 mac host system connection 1-13 1.8 centralized statistics updater 1-15 1.9 multiple channel application 1-18 1.10 external connections to the E-110 mac 1-19 1.11 mii function 1-21 1.12 miim core 1-23 2.1 E-110 mac core interface diagram 2-2 2.2 mac control module core interface diagram 2-28 2.3 miim core interface diagram 2-35 3.1 overall block diagram 3-4 3.2 transmit and receive functions 3-5 3.3 transmit function interface 3-5 3.4 half-duplex back-to-back ipg operation 3-7 3.5 half-duplex non back-to-back ipg operation 3-8 3.6 full-duplex back-to-back ipg operation 3-8 3.7 full-duplex non back-to-back ipg operation 3-9 3.8 receive function interface 3-14 4.1 E-110 mac receive packet timing 4-2 4.2 packet preamble and sfd 4-3 4.3 E-110 mac transmit packet timing 4-5 4.4 miim write operation 4-7 4.5 miim read operation 4-8 4.6 transmit collision functional timing 4-10 5.1 mac core setup, hold, and delay timing diagram 5-2
vi contents 5.2 mac control module setup, hold, and delay timing diagram 5-7 5.3 miim core setup, hold, and delay timing diagram 5-10 tables 1.1 10base-t ethernet vs. 100base-t fast ethernet 1-5 2.1 transmission retry algorithm for bkoff_limit[1:0] (maximum k = 10, 8, 4, 1) 2-16 3.1 miim register set 3-18 3.2 phy control register bit de?nitions 3-20 3.3 phy status register bit de?nitions 3-21 5.1 mac core ac timing parameters 5-3 5.2 mac core pin summary 5-4 5.3 mac control module ac timing parameters 5-7 5.4 mac control module pin summary 5-8 5.5 miim core ac timing parameters 5-10 5.6 miim core pin summary 5-11
preface vii preface this manual is the primary reference for the ethernet-110 (E-110) core, which includes the media access controller (mac) core, the optional mac control module core, and the optional media independent interface management (miim) core. it contains a complete functional description for the E-110 core and includes complete physical and electrical speci?cations. the E-110 core is capable of operating at 10 or 100 mbit/s for ethernet and fast ethernet applications. audience this manual assumes that you have some familiarity with ethernet protocols and related support devices. it also assumes some familiarity with ieee standards 802.3/802.3u and all applicable clauses describing 10- and 100-mbit/s ethernet operation. the people who bene?t from this technical manual are: engineers and managers who are evaluating the E-110 core for use in an asic application engineers who are designing the E-110 core into an asic organization this document has the following chapters: chapter 1, introduction , provides an introduction to lsi logic corporations E-110 core. chapter 2, signal descriptions , provides a detailed description of each of the signals associated with the core. chapter 3, core description , describes the operation of the E-110 core.
viii preface chapter 4, functional timing , provides timing diagrams for the core. chapter 5, speci?cations , describes the ac timing and core inputs and outputs. appendix a, glossary , provides a list of terms used in this manual. related publications ieee standard 802.3, 10 mbit/s ethernet speci?cation . ieee standard 802.3u, 100base-t fast ethernet speci?cation . ieee standard 802.3x, 802.3 full duplex operation speci?cation . ethernet-10 (e-10) core technical manual , lsi logic corporation, order number r14006. conventions used in this manual the ?rst time a word or phrase is de?ned in this manual, it is italicized . see the glossary at the end of this manual for de?nitions of italicized words. the word assert means to drive a signal true or active. the word deassert means to drive a signal false or inactive. the following signal naming conventions are used throughout this manual: a level-signi?cant signal that is true or valid when the signal is low always has a suf?x of _l attached to its name. an edge-signi?cant signal that initiates actions on a high-to-low transition always has a suf?x of _l attached to its name. hexadecimal numbers are indicated by the pre?x 0x before the numberfor example, 0x32cf. binary numbers are indicated by the pre?x 0b, for example, 0b0011.0010.1100.1111.
1-1 chapter 1 introduction this chapter describes the overall functions of the E-110 core. it contains the following sections: section 1.1, coreware ? program section 1.2, fast ethernet (100 mbit/s) section 1.3, E-110 core section 1.4, E-110 mac core section 1.5, mac control module core section 1.6, miim core 1.1 coreware ? program an lsi logic core is a fully de?ned and reusable block of logic. it supports industry-standard functions, and has prede?ned timing and layout. every core possesses signi?cant intellectual property value that comes from the construction, optimization, and productization of a particular function. through the coreware program, you can create systems on a chip uniquely suited to your applications. the coreware library contains a wide range of complex cores targeting the communications, consumer, and computer markets. the library consist of mips microprocessor cores, high-speed interconnect cores, mpeg-2 decoder cores, pci cores, and many more. the coreware library also includes megafunctions and building blocks, which provide useful functions for developing a system on a chip.
1-2 introduction each core has an associated set of deliverables, including: rtl simulation models for the verilog hdl environment structural simulation models for verilog hdl and vhdl environments a system veri?cation environment (sve) 1 for rtl-based verilog simulation a test vector suite because your design requirements are unique, lsi logic is ?exible in working with you to develop your system-on-a-chip coreware design. three different working relationships are available: you provide lsi logic with a detailed speci?cation and lsi logic does all of the design. you design some functions while lsi logic provides you with the cores and megafunctions, and lsi logic completes the integration. lsi logic provides you with the cores, megafunctions, and development tools for you to do the entire design and integration. whatever the work relationship, lsi logics advanced coreware methodology and asic process technologies consistently produce right-first-time? silicon. 1.2 fast ethernet (100 mbit/s) the E-110 core is a 100base-t fast ethernet solution. 100base-t is one of a number of technologies that provide greater bandwidth and improved client/server response times. the 100base-t standard is designed to provide a smooth evolution from 10base-t ethernetthe dominant 10-mbit/s network used todayto high-speed 100-mbit/s performance. 1.2.1 fast ethernet overview the fast ethernet standard for 100base-t has been established by the ieee 802.3 committee, the same committee that developed the original 1. the sve provides a software environment for verifying core functionality.
fast ethernet (100 mbit/s) 1-3 ethernet standard. the 100base-t standard is found in the ieee 803.3u speci?cation, which serves as a supplement to the 802.3 standard and extends the operating speed to 100 mbit/s. 100base-t fast ethernet is an extension of 10base-t technology. this technology uses the existing 802.3 media access control (mac) layer (layer 2), connected through a media-independent interface (mii) to a physical layer device (phy). the mii speci?cation is analogous to the 10-mbit/s ethernet attachment unit interface (aui) it provides a single interface that can support external transceivers for any of the 100base-t media speci?cations. in the fast ethernet mac, the bit time (the time to transmit one bit of data) has been reduced by a factor of 10, thereby increasing packet speed to ten times that of 10base-t, while packet format and length, error control, and management information remain identical to 10base-t. the 100base-t standard supports three phy layers: 100base-tx (see ieee 802.3u, clauses 24 and 25) 100base-t4 (see ieee 802.3u, clause 23) 100base-fx (see ieee 802.3u, clauses 24 and 26) the 100base-x standard outlined in the ieee 802.3u speci?cation embodies the 100base-tx and 100base-fx standards. the term 100base-x is used when referring to the physical coding sublayer (pcs) and physical medium attachment (pma), which are common to both 100base-tx and 100base-fx. see figure 1.2 on page 1-7. the physical medium dependent (pmd) issues are different for 100base-tx and 100base-fx, and are described in separate sections of the ieee 802.3u speci?cation. the 100base-t4 standard is unique from 100base-tx and 100base-fx and is described in its own section of the ieee 802.3u speci?cation. the 100base-t standard also de?nes a universal hub interface and a management interface. the cable and ?ber types currently used in 100base-t networks are: 100base-tx a two-pair system for data grade (eia 568 category 5) unshielded twisted-pair (utp) and 150- w shielded twisted-pair (stp) cabling
1-4 introduction 100base-t4a four-pair system for both voice and data grade (category 3, 4, or 5) utp cabling 100base-fx two multimode ?bers additionally, the 100base-tx, 100base-t4, and 100base-fx systems can be mixed and interconnected through a hub. 1.2.2 fast ethernet features the key advantages of fast ethernet: proven technology with speed increased by a factor of 10 simple migration from 10-mbit/s to 100-mbit/s networks extensive multivendor support 1.2.2.1 10base-t to 100base-t comparison fast ethernet, in the form of 100base-t technology, is really very similar to 10base-t, but is ten times faster. unlike other high-speed technologies, ethernet has been installed for over 20 years in business, government, and educational networks. table 1.1 is a comparison between 10base-t and 100base-t.
fast ethernet (100 mbit/s) 1-5 1.2.2.2 csma/cd transmission protocol ethernets fundamental transmission protocol is carrier sense multiple access with collision detection (csma/cd) . fast ethernet maintains this protocol, which allows it to move data between 10base-t and 100base-t stations on a local area network (lan) without requiring protocol translation. a simple, low-cost switching hub or bridge is all that is required for connection. because it is the same technology (but faster), 100base-t can be successfully integrated into 10base-t networks to form a reliable migration path to 100base-t networks. 1.2.2.3 media speci?cations a major advantage of fast ethernet over other high-performance technologies is that it can be deployed as a switching or shared technology. 100base-t networks are based on a combination of table 1.1 10base-t ethernet vs. 100base-t fast ethernet function ethernet fast ethernet speed 10 mbit/s 100 mbit/s ieee standard 802.3 802.3u media access protocol csma/cd csma/cd topology bus or star star cable support coax, utp, fiber utp, fiber utp 1 cable support category 3, 4, or 5 category 3, 4, or 5 utp link distance (max) 100 meters 100 meters collision domain diameter (maximum with all utp) 500 meters 205 meters maximum network diameter (using switches/routers) unlimited unlimited media independent interface? yes (aui) 2 yes (mii) 3 full duplex capable? yes yes 1. utp = unshielded twisted pair 2. aui = auxiliary unit interface 3. mii = media independent interface
1-6 introduction switching and shared hubs in order to maintain existing 10base-t infrastructures. 100base-t networks are capable of full-duplex operation. 100base-t combines the scaled mac with a variety of media speci?cations to provide users with the maximum possible wiring ?exibility, as shown in figure 1.1. the media speci?cations (100base- tx, 100base-t4, and 100base-fx) are collectively referred to as 100base-t and enable users to retain their existing cabling infrastructure while migrating to fast ethernet. figure 1.1 100base-t media speci?cations 1.2.3 E-110 mac core and the osi model figure 1.2 shows how the E-110 mac ?ts into the iso open systems interconnection (osi) reference model. the osi model de?nes a data communications protocol consisting of seven distinct layers. four-pair utp (100base-t4) csma/cd mac csma/cd mac scaled by 10x thick coax (10base5) thin coax (10base2) fiber (100base-fx) fiber (10base-f) twisted-pair (10base-t) two-pair utp, stp (100base-tx) 10 mbit/s ethernet 100 mbit/s fast ethernet 100base-t
fast ethernet (100 mbit/s) 1-7 figure 1.2 E-110 mac relationship to the osi model overviews of the operation of the mac core, mac control module core, and the miim core are found later in this chapter. 1.2.4 fast ethernet hubs a hub is a common wiring point for star-topology networks, and can perform various functions, such as switching, statistics gathering, and signal retiming. the E-110 core provides a high-integration solution to hub design because several cores may be placed on a single asic. figure 1.3 illustrates how hubs might be con?gured using the E-110 core. application (7) presentation (6) session (5) transport (4) network (3) data link (2) physical (1) osi reference model layers lan csma/cd layers higher layers llc = logical link control mac = media access control reconciliation mii pcs pma pmd medium phy mdi mdi = media-dependent interface mii = media-independent interface pcs = physical coding sublayer phy = physical layer device E-110 mac core pmd = physical medium dependent llc mac pma = physical medium attachment
1-8 introduction figure 1.3 hub examples a a switching hub facilitates packet switching. each port of a packet switching hub provides a connection to an ethernet media system that operates as a separate ethernet lan . unlike a repeater hub whose individual ports combine segments together to create a single large lan, a switching hub makes it possible to divide a set of ethernet media systems into multiple lans that are linked together by way of the packet switching electronics in the hub. the round trip timing rules for each lan stop at the switching hub port, allowing you to link a large number of 100 mbit/s switching hub 10 mbit/s multiport switching hub 10 mbit/s 10 mbit/s 100 mbit/s multiport switching hub 100 mbit/s 100 mbit/s 100 mbit/s 100 mbit/s 100 mbit/s 10/100 mbit/s multiport switching hub 100 mbit/s 10 mbit/s pc pc pc pc pc pc pc workstation workstation workstation workstation E-110 core E-110 core E-110 core E-110 core E-110 core E-110 core E-110 core E-110 core E-110 core E-110 core 10 mbit/s E-110 core 100 mbit/s
fast ethernet (100 mbit/s) 1-9 individual ethernet lans together. a given ethernet lan can consist of a single cable segment linking some number of computers, or it may consist of a repeater hub linking several such media segments together. whole ethernet lans can themselves be linked together to form extended network systems using packet switching hubs. while an individual ethernet lan may typically support anywhere from a few up to several dozen computers, the total system of ethernet lans linked with packet switches at a given site may support many hundreds or thousands of machines. a switching hub can be designed with an intelligent switching fabric and multiple E-110 cores. the switching may be done in any of the following manners: cut-throughthe head of the frame leaves the switch before the tail has arrived. you use an address compare buffer to decode the destination address. store and forwardthe entire frame is received and buffered before being forwarded to an output port. adaptive cut-throughthe hub looks at collision statistics. if too many collisions occur, the hub changes from cut-through operation to store and forward operation.
1-10 introduction figure 1.4 shows where the E-110 core ?ts in a switched hub. figure 1.4 switched hub example 1.2.5 fast ethernet network interface cards network cards can be designed with the E-110 core that will run at speeds of 10 or 100 mbit/s. figure 1.5 shows how the E-110 core ?ts into a network interface card (nic). the E-110 core provides the mac function and interfaces with 10 mbit/s or 100 mbit/s phys for single- or multi-point server solutions. switching fabric (asic) port 1 connected to port 3 port 4 connected to port 2 port 6 connected to port 5 mii E-110 core switching intelligence, buffering, store and forward mii E-110 core mii E-110 core switching fabric details switched hub 6 5 4 3 2 1
E-110 core 1-11 figure 1.5 network interface card block diagram 1.3 E-110 core as shown in figure 1.6, the E-110 core contains the following cores: mac mac control module (optional) miim (optional) host interface 10 or 100 mbit/s twisted-pair or edge connector to pc fiber-optic media phy customer asic E-110 coremac and miim
1-12 introduction figure 1.6 E-110 asic environment the mac 1 core operates at 10 or 100 mbit/s using an external phy. an optional mac control module core located external to the E-110 core allows the host to perform the ?ow control functions given in the ieee 802.3/802.3u standard. an optional miim core allows a host to communicate with the control and status registers within an mii- supported phy. 1. the mac is capable of 10- or 100-mbit/s operation. 2. an optional miim core reads phy status registers and writes phy control registers. 3. an optional mac control module core provides the ?ow control functions. media E-110 core mac core 1 100base-t host mac control module core 3 transmit function receive function miim core 2 transmit logic receive logic miim data mii transmit data mii receive data = optional mii- supported phy control/status 1. the mac function meets the requirements of the ieee 802.3u speci?cation.
E-110 mac core 1-13 1.4 E-110 mac core the E-110 mac core consists of the transmit and receive functions. the transmit and receive functions transport data between the mac functions host interface and the mii. data consists of bytes on the host side and nibbles on the mii side. the host provides some data buffering and logic to manage properly the receive and transmit data streams. the mii is a logical data interface only. the user must provide line drivers and receivers to meet cable interface or attachment unit interface requirements. 1.4.1 mac core host system connection the E-110 mac core is connected to a host system as shown in figure 1.7. the following host connections are explained in this section: system data flow statistics vectors interface host processor interface figure 1.7 E-110 mac host system connection E-110 mac function receive transmit address logic receive byte stream host processor interface statistics vectors interface host system user-speci?c functions recognition logic logic transmit byte stream data/control and control data
1-14 introduction 1.4.1.1 system data flow the E-110 mac operates at either 10 or 100 mbit/s between an mii on one side and a host on the other. the receive and transmit data streams are independent from each other on both sides of the mac. the receive byte stream from the E-110 mac operates on the mii receive clock. another element of the overall system may assemble bytes from the receive byte stream into words for storage in a buffer memory or transmission to a system bus. alternatively, the receive byte stream might enter directly into a fifo. the output of the fifo could then be interfaced into the overall system in a variety of ways, possibly using a common system clock. the transmit byte stream for the E-110 mac operates on the mii transmit clock. another element of the overall system may disassemble words read from a buffer memory or received from a system bus into bytes for the transmit byte stream. alternatively, the transmit byte stream might exit directly from a fifo. the input of the fifo could then be fed from the overall system in a variety of ways, possibly using a common system clock. logic associated with the transmit and receive byte streams handles the packet and data ?ow control between the overall system and the E-110 mac. speci?cally, a device external to the E-110 mac must monitor the receive byte stream to perform receive address recognition. details of the receive byte stream interface can be found in section 3.2.1.2, mac receive function, on page 3-13. an explanation of the transmit byte stream interface can be found in section 3.2.1.1, mac transmit function, on page 3-5. E-110 mac behavior can be altered with external control signals. a description of the control signals is given in chapter 2. 1.4.1.2 statistics vectors interface the E-110 mac collects packet-by-packet statistics, but does not include statistics event counters or accumulating byte counters. statistics for management purposes are collected outside the E-110 mac for either end station or multiple channel applications. figure 1.8 shows how a centralized statistics collector for use with multiple E-110 macs might be constructed.
E-110 mac core 1-15 figure 1.8 centralized statistics updater whenever the E-110 mac receive and transmit functions complete the processing of a packet, the mac creates a transmit or a receive statistics vector that may be latched external to the mac function for use by the statistics updating process. because the vector is latched, the receive and transmit functions do not hold the statistics vectors inde?nitely. it then becomes the responsibility of the host to free up enough statistics storage space before the mac overwrites the vectors with those for the next processed packet. when the mac latches the receive and transmit statistics vectors, the mac provides synchronized latching signals for each of the transmit and receive vectors. the vectors include packet length bits that specify the length of the packet in bytes. in the example block diagram of figure 1.8, the statistics updater synchronizer feeds the arbiter, which schedules the updating of statistics in the statistics storage. the statistics subsystem usually operates on the host system microprocessor clock, transmit statistics vector latch receive statistics vector latch receive statistics vector transmit statistics vector synchronizer arbiter statistics updater statistics storage channel 1 ? ? ? host system processor host system processor interface mac user-speci?c functions transmit statistics vector latch receive statistics vector latch receive statistics vector transmit statistics vector channel n user-speci?c functions E-110 mac E-110
1-16 introduction which means that accesses to the statistics storage by the host are automatically synchronized. however, the transmit and receive statistics vector latch pulse must be synchronized to the host system clock because the transmit and receive functions operate on their own clocks. 1.4.1.3 host processor interface the host system processor has the following connections to the E-110 mac: mii data interface random number generator interface control interface statistics interface mii data interface C the E-110 mac sends and receives data to the mii-supported phy by means of the mii transmit data and receive data signal lines, over which the mac passes transmit and receive nibbles. random number generator interface C the E-110 mac contains a random number generator that is used for transmit backoff in the event of a collision. the host may optionally load an 11-bit seed value into the random number generator. by loading different seed values into each E-110 mac in a multiple-mac system, you can guarantee that the backoff timers in each mac are not synchronized to each other, which avoids the problem of two or more macs colliding repeatedly while attempting to transmit. if you do not load a seed value in the random number generator, there is a chance that two macs might have the same backoff timer value. control interface C the host control interface allows the host to directly control the operation of the E-110 mac. the host must provide either a 25- or 33-mhz clock (hclk) to the core. the core uses the clock select (clks) input signal from the host to determine how to divide down hclk to create the miim data clock (mdc) signal. the host provides a variety of control signals to the mac function to control the following: interpacket gaps (see section 3.2.1.1, mac transmit function, and the signal descriptions for ipgr1[6:0], ipgr2[6:0], and ipgt[6:0] in chapter 2).
E-110 mac core 1-17 padding of packets (see the subsection entitled ipg full-duplex operation and the signal descriptions for nopre and paden in chapter 2). preamble (see the subsection entitled ipg full-duplex operation and the signal description for nopre in chapter 2). full duplex operation (see the subsection entitled ipg full-duplex operation?" the signal description for fulld under section 2.1.4, mii to phy signals, and the signal description for fulld in chapter 2). frame check sequence (fcs) checking (see the subsection entitled ipg full-duplex operation?" section 3.2.1.2, mac receive function, the subsection entitled receive function to host interface?" and the signal descriptions for crco[9:1], crcg, crcen, and nopre in chapter 2). maximum packet length (see the subsection entitled ipg full-duplex operation?" section 3.2.1.2, mac receive function, and the signal description for hugen in chapter 2). late collisions (see the subsection entitled ipg full-duplex operation?" and the signal description for tpab and rtryl in chapter 2). 10- or 100-mbit/s operation (see table 3.2). statistics interface C the E-110 mac function provides receive and transmit statistics data that can be latched by a device external to the function and then read by the host. the mac function provides the information on a parallel interface along with strobe signals. 1.4.2 mac multiple channel operation while the E-110 mac function can be used in a single-channel environment as shown in figure 1.6, the same design can also be used for multiple channel applications as shown in figure 1.9.
1-18 introduction figure 1.9 multiple channel application the exact nature of the common sections in figure 1.9 is highly application dependent. the mii signal lines are only logical implementations without the line driving capability. 1.4.3 mac external interfaces the E-110 mac operates at either 10 mbit/s or 100 mbit/s between a mii on one side and a system data transport on the other. the system designer can design the E-110 mac into both end station, switch, and hub environments. for system ef?ciency in multiple mac situations, you may provide a module external to the mac function to collect statistics on mac events and perform receive packet address recognition. statistics collection and receive packet address recognition are customer de?ned for use with the E-110 mac. figure 1.10 illustrates the connections to the E-110 mac function. mii phy common common host interface mii mii mii mii mii mii mii 1. data transport, address recognition, and statistics collection. functions 1 phy phy phy phy phy phy phy E-110 mac E-110 mac E-110 mac E-110 mac E-110 mac E-110 mac E-110 mac E-110 mac
E-110 mac core 1-19 figure 1.10 external connections to the E-110 mac for simplicity of application, all per packet interactions (for example, start of frame and end of frame) between the E-110 mac and the system take place through the system data transport. using the system data transport eliminates the need for involvement of a processor at 100 mbit/s because the E-110 mac takes over the per packet data transfer responsibility. the E-110 mac conforms to existing ieee 802.3 standards for 10-mbit/s operation and ieee 802.3u standards for 100-mbit/s operation. it is expected that a common application of the E-110 mac will be as a part of a larger system in user-speci?c asics. the E-110 mac therefore imposes very little system personality regarding word size, byte order, data ?ow methodology, or management conventions. alternatively, the E-110 mac can be combined with a minimum of logic circuitry connected to off-chip interfaces to con?gure a unique mac device. to allow for a variety of network media types and methods of connection to the media, the mii standard has been adopted for the E-110 mac. the E-110 mac uses the mii on a logical basis only. any implementation of the E-110 mac can be used to connect copper wire or fiber media by means of a phy. the phy can reside either within the same asic as the E-110 mac or external to the asic, as long as the phy interface to the E-110 mac is mii-compatible. the E-110 mac function transmits and receives nibbles of data to and from the media over the mii signal lines. the function handles independent receive and transmit byte streams between mii devices and the host. on the host side of the E-110 mac, the byte streams can be directed into a system memory or bus structure in a variety of ways, such as shared or separate dma channels or direct access to multiple port memories and fifos. the byte streams can also be assembled into system words as desired. E-110 mac statistics collection system data transport mii control host address recognition mii
1-20 introduction management statistics collection is not included in the E-110 mac. to facilitate statistics collection, the mac function incorporates statistics vector circuitry to simplify the accumulation of event statistics. if statistics collection logic is desired, internal or external to the asic, it must be designed and implemented by the end user. to allow for simple end station and complex switching hub environments, you may add receive packet address recognition logic external to the mac function. lsi logic does not supply the address recognition logic. for end station applications, a simple single station address comparison module can be attached to the receive byte stream. a hashing multicast capability can also be included in this module to detect sets of destination addresses. for switching hub applications, a central source and destination address ?lter block is often the preferred solution. the E-110 mac function transmit and receive byte streams can interact with such a block. 1.4.4 mac mii the E-110 mac operates with the mii signal lines connecting to physical media interface devices. the mii is a logical data interface only. the designer must provide line drivers and receivers to meet cable interface or aui requirements. figure 1.11 shows that a processor can control a phy through an E-110 mac that incorporates an mii function.
E-110 mac core 1-21 figure 1.11 mii function as new mii phys become available, they can be attached to the E-110 mac, providing increased capability at both 10 mbit/s and 100 mbit/s. you can continue to interface to the phys by means of the E-110 macs built-in mii function. 1.4.5 mac backoff operation when a data collision occurs, the mac must perform a backoff operation, which causes the mac to wait for a time and then try retransmitting. the mac implements two selectable backoff methods: stop backoff truncate backoff 1.4.5.1 stop backoff the stop backoff feature is implemented with the tboff_sel input pin. the tboff_sel input, driven by the host, controls whether the E-110 core uses the binary exponential backoff algorithm during collisions. see chapter 2, signal descriptions, for a detailed signal description. transmit function external phy mii signals receive function mii signals mac (mii or pmd) E-110 core 8 8 4 bits/25 mhz 1 or 4 bits/2.5 mhz 2 4 bits/25 mhz 1 or 4 bits/2.5 mhz 2 notes: the clock rate is 25 mhz, which yields 100 mbit/s 1. 4 bits/25 mhz means that the data path is 4 bits wide (a nibble) and that 2. 4 bits/2.5 mhz means that the data path is 4 bits wide (a nibble) and that the clock rate is 2.5 mhz, which yields 10 mbit/s
1-22 introduction the stop backoff implementation does not conform to the ieee 802.3/802.3u standard, but may be useful for test purposes. 1.4.5.2 truncate backoff the truncate backoff feature is implemented with the bkoff_limit[1:0] input pins, which are driven by the host. the truncate backoff feature gives the user some ?exibility in achieving a performance advantage in some native applications. with the truncate backoff feature, the E-110 core can be con?gured for either more or less aggressive backoff behavior, depending on the users choice. see chapter 2, signal descriptions, for a detailed signal description. 1.4.6 mac backpressure feature the mac core implements a backpressure feature, which is implemented with the false carrier sense (fls_crs) input pin. the pin is driven by the host, and is applicable when the E-110 mac core is used in a half- duplex switched port design. when using a switch (rather than a repeater) as the hub for an ethernet lan, it is possible for traf?c to arrive at a switched port faster than the switch is able to transmit the traf?c out to the target destination port. making the channel appear busy to the transmitter is an effective and ef?cient way of stopping the transmitter from ?ooding the receivers buffers. the use of the fls_crs signal is especially clean when only one end station is connected to each switch portin these cases, fls_crs throttles the end station as needed. see chapter 2, signal descriptions, for a detailed signal description of the fls_crs signal. 1.5 mac control module core the mac control module is an optional core that interfaces the E-110 core to the host and implements full-duplex ?ow control. in full-duplex ethernet, neither false carrier sense nor forced collision algorithms solve congestion control problems. a full-duplex ethernet station does not implement collision detection and ignores carrier sense for deferring transmissions. a full-duplex ethernet implementation
miim core 1-23 therefore requires an explicit ?ow control mechanism to allow a switch to throttle a congesting end station. clause 31 in the ieee 802.3/802.3u standard de?nes the frame-based ?ow control scheme implemented in the mac control module core. 1.6 miim core the optional miim core allows the host to write control data to and read status information from any of 32 registers in any of 32 phys using the miim interface. the miim interface is a 16-bit parallel interface on the miim cores host side and a serial interface on the cores mii side. the miim interface allows the host to send control data and receive status information from phys over the mac mii interface. the host can select one of 32 phys and one of 32 registers within any phy and then send control data or receive status information. only one register in one phy can be addressed at any time. for more details on the communication from the host to the phys, refer to the reconciliation sublayer and media independent interface speci?cations section of the ieee 802.3u speci?cation, 100base-t fast ethernet. the host sends control data to the phy and receives status information from the phy through the miim module, as shown in figure 1.12. figure 1.12 miim core mii-supported phy mii management mii data host control and status lines host registers management core
1-24 introduction
2-1 chapter 2 signal descriptions this chapter provides detailed descriptions of the signals for the E-110 core. these signal descriptions are useful for designers who will be interfacing the E-110 core with other core logic or external logic. this chapter contains the following sections: section 2.1, mac core signals section 2.2, mac control module signals section 2.3, miim core signals please see the subsection entitled conventions used in this manual on page viii of this manual for a description of how signals are named. 2.1 mac core signals the interface diagram for the E-110 mac core is shown in figure 2.1. the mac signals fall into the following groups: transmit function receive function mac control module mii to phy scan test host control statistics vectors random number generator
2-2 signal descriptions figure 2.1 E-110 mac core interface diagram tpud tpd[7:0] tpef tpur tprt transmit function rpd[7:0] 1 crco[9:1] crcg bco mco byte7 receive function mtxen mtxd[3:0] mtxer mcrs mcol mtxc mrxdv mrxd[3:0] mrxer mrxc mii ipgt[6:0] ipgr1[6:0] ipgr2[6:0] nopre paden fulld crcen hugen hrst_l tsv[30:0] tsvp_l rsv[25:0] control signals statistics hwd[10:0] lrng random number generator E-110 mac core rtryl host to host signals to host signals to host signals to phy signals vectors to host signals tboff_sel bkoff_limit[1:0] fls_crs trst_l 1 1. these signals are also connected to the optional mac control module core, if it is used. rrst_l 1 tpdn 1 rpsf 1 rpef 1 rpdv 1 rsvp_l tpab 1 tmode test_se scan test signals test_si test_so tpsf 1
mac core signals 2-3 2.1.1 transmit function to host signals below is a list of the signals between the E-110 mac transmit function and the host transmit buffer. all signals are active high unless otherwise noted. all signals are synchronous with the rising edge of the mii phy transmit clock (mtxc). signal direction is with respect to the transmit function block. see the section 3.2.1.1, mac transmit function, on page 3-5 for further details on transmit buffer and transmit function interaction. tpab transmit packet abort output when asserted, the tpab signal indicates that the trans- mission was discontinued. tpab remains asserted until the E-110 mac function receives a request to transmit, which is indicated when the mac control module asserts tpsf. when deasserted, tpab indicates that the trans- mission was not aborted. the following circumstances cause the transmission to be halted: excess deferrals , which occur when the media is busy longer than twice the maximum frame length (greater than 24,288 1 bits when the hugen signal is deas- serted or greater than 524,288 2 bits when hugen is asserted) late collision (use rtryl to avoid aborting) multiple collisions (greater than 15) transmit underrun larger than normal packet, which is 1518 bytes (see also see the hugen signal description) the tpab signal is also connected to the optional mac control module core. tpd[7:0] transmit packet data input the tpd[7:0] signals are the transmit data bus. the host must hold the tpd[7:0] signals valid for exactly two mtxc clock cycles. 1. 24,288 bits = 1518 byte s x 8 bits/byte x 2 (242.88 m s for 100-mbit/s operation or 2.4288 ms for 10-mbit/s operation) 2. 524,288 bits = 32 kbytes x 8 bits/byte x 2 (5242.88 m s for 100-mbit/s operation or 52.43 ms for 10-mbit/s operation)
2-4 signal descriptions tpdn transmit packet done output when asserted, the tpdn signal indicates successful completion of the packet transmit process. the mac keeps tpdn asserted until the mac receives a fresh request to transmit, which is indicated when the mac control module asserts the tpsf signal. the tpdn signal is also connected to the optional mac control module core. tpef transmit packet end of frame input the host asserts the tpef signal to indicate the last byte of the transmit packet is available from the host. tpef must be valid for two mtxc clock periods before it is deasserted. tprt transmit packet retry output the mac asserts the tprt signal to indicate that the mac function encountered at least one collision during a transmit attempt. the mac asserts tprt until the mac receives a fresh request to transmit, which is indicated when the mac control module asserts tpsf. tpsf transmit packet start of frame input the mac control module, if implemented, asserts the tpsf signal to request the E-110 core to transmit a new packet. if the mac control module is not implemented, the host must assert the tpsf signal. this paragraph describes how the host must control the tpsf signal. the host interface asserts the tpsf signal to request the mac to transmit a new packet. the host must keep the tpsf signal asserted for one transmit clock period after the E-110 core asserts the tpud signal. the tpsf signal is synchronous to mtxc. for a description of how the mac control module controls the tpsf signal, see section 2.1.3, mac control mod- ule signals (optional) on page 2-7. tpud transmit packet data used output the E-110 mac function asserts the tpud signal to indicate that the preamble has been transmitted. every two clocks thereafter, the host must place the tpd[7:0] signals on the bus for the mac. the mac keeps tpud asserted until the mac accepts all the data bytes in the transmit packet from the host.
mac core signals 2-5 tpur transmit packet data underrun input when the tpur signal is asserted, the E-110 mac func- tion discontinues transmission. if the host is unable to supply transmit packet data bytes in a timely manner to the E-110 core (an underrun condition), the host must assert tpur. the host must assert tpur for at least two mtxc clock cycles. trst_l transmit reset output other modules in an asic can use the trst_l signal as a host reset synchronized to the transmit clock (mtxc). because the mtxc clock can be slow with respect to a host reset pulse, or even stopped, the host reset signal (hrst_l) is captured in the E-110 mac transmit func- tion. the transmit function asserts trst_l asynchro- nously to mtxc when the hrst_l signal occurs and deasserts trst_l synchronously on the positive transition of mtxc. modules can use trst_l to initialize transmit logic. the trst_l signal is also connected to the optional mac control module core. 2.1.2 receive function to host signals below is a list of the signals between the E-110 mac receive function and the host receive logic. all signals are active high unless otherwise noted. all signals are synchronous with the mrxc rising edge. signal direction is with respect to the receive function block. see section 3.2.1.2, mac receive function, on page 3-13 for further details on receive buffer and receive function interaction via these signals. bco broadcast out output when asserted, the bco signal indicates that the received packet is a broadcast packet . a broadcast packet has the destination address ?eld set to all ones, which indicates it is being sent to all destinations on the network. when deasserted, bco indicates that the received packet is not a broadcast packet. byte7 must be asserted for this output to be valid. byte7 byte 7 output when asserted, the byte7 signal indicates that the bco and mco bits are valid. when deasserted, the byte7 sig- nal indicates that the bco and mco signals are not valid.
2-6 signal descriptions crco[9:1] crc out output the crco[9:1] signals re?ect the state of the receive function fcs register after the ?rst six bytes of the receive packet have been received. when the destination address bits that are received in the frame contain a mul- ticast address, the E-110 core uses its built-in fcs gen- erator to compute a nine-bit polynomial (the nine msbs of the 32-bit fcs generator) from the incoming address. the value of this polynomial can be used as an index into an external multicast ?lter hash table. external logic can decide to either accept or reject the incoming frame. crcg crc good output the crcg signal, when asserted, indicates that the crco[9:1] signals are valid. the crcg signal, when deasserted, indicates that the crco[9:1] signals are not valid. mco multicast out output when asserted, the mco signal indicates that the received packet is a multicast packet (a packet that is being sent to selected stations on the network). when deasserted, mco indicates that the received packet is not a multicast packet, which means that it could be an individual or broadcast packet. byte7 must be asserted for mco to be valid. rpd[7:0] receive packet data output the rpd[7:0] signals are the receive data bus. the sig- nals hold the received data byte for two mrxc clock cycles. the rpd[7:0] signals are also connected to the optional mac control module core. rpdv receive packet data valid output a packet transmission from the receive function to the host receive control logic (see figure 1.6 on page 1-12) begins when the receive function asserts the rpsf and rpdv signal at the ?rst byte of received packet data on rpd[7:0] after removing the preamble and sfd. for sub- sequent data bytes, the receive function asserts only the rpdv signal until the last byte, when it asserts both rpdv and rpef. see figure 4.1 on page 4-2 for receive packet timing. the rpdv signal is also connected to the optional mac control module core.
mac core signals 2-7 rpef receive packet end of frame output the mac asserts the rpef signal for one mrxc clock cycle to indicate that the last byte of the receive packet is available to the mac control module on rpd[7:0]. the rpef signal is also connected to the optional mac control module core. rpsf receive packet start of frame output the mac asserts the rpsf signal for one mrxc clock cycle to indicate that the ?rst byte of a receive packet is available to the host on rpd[7:0]. the rpsf signal is also connected to the optional mac control module core. rrst_l receive reset output other modules in an asic can use the rrst_l signal as a host reset synchronized to the receive clock (mrxc). because the mrxc clock can be slow with respect to a host reset pulse, or even stopped, the host reset signal (hrst_l) is captured in the E-110 mac receive function, which asserts rrst_l asynchronously to mrxc when hrst_l occurs and deasserts rrst_l synchronously on the positive transition of mrxc. the rrst_l signal is also connected to the optional mac control module core. rsvp_l receive statistics vector pulse output the rsvp_l signal is active low. when the mac asserts rsvp_l, it indicates that the rsv[25:0] signals have been updated with a new receive statistics vector. when deasserted, it indicates that there has been no update. the rsvp_l signal is also connected to the optional mac control module core. 2.1.3 mac control module signals (optional) below is a list of the signals that interface between the E-110 core and the optional mac control module core. (see also section 2.2, mac control module signals, on page 2-28.) all signals are active high unless otherwise noted. signal direction is with respect to the E-110 core. rpd[7:0] receive packet data output the rpd[7:0] signals are the receive data bus. the signals hold the received data byte for two mrxc clock cycles. the rpd[7:0] signals are also connected to the host.
2-8 signal descriptions rpdv receive packet data valid output a packet transmission from the receive function to the host receive control logic (see figure 1.6 on page 1-12) begins when the receive function asserts the rpsf and rpdv signal at the ?rst byte of received packet data on rpd[7:0] after removing the preamble and sfd. for sub- sequent data bytes, the receive function asserts only the rpdv signal until the last byte, when it asserts both rpdv and rpef. see figure 4.1 on page 4-2 for receive packet timing. the rpdv signal is also connected to the host. rpef receive packet end of frame output the mac asserts the rpef signal for one mrxc clock cycle to indicate that the last byte of the receive packet is available to the mac control module on rpd[7:0]. the rpef signal is also connected to the host. rpsf receive packet start of frame output the mac asserts the rpsf signal for one mrxc clock cycle to indicate that the ?rst byte of a receive packet is available to the host on rpd[7:0]. the rpsf signal is also connected to the host. rrst_l receive reset output other modules in an asic can use the rrst_l signal as a host reset synchronized to the receive clock (mrxc). because the mrxc clock can be slow with respect to a host reset pulse, or even stopped, the host reset signal (hrst_l) is captured in the E-110 mac receive function, which asserts rrst_l asynchronously to mrxc when hrst_l occurs and deasserts rrst_l synchronously on the positive transition of mrxc. the rrst_l signal is also connected to the host. tpab transmit packet abort output when asserted, the tpab signal indicates that the trans- mission was discontinued. tpab remains asserted until the E-110 mac function receives a request to transmit, which is indicated when the mac control module asserts tpsf. when deasserted, tpab indicates that the trans- mission was not aborted. the following circumstances cause the transmission to be halted: excess deferrals, which occur when the media is busy longer than twice the maximum frame length (greater
mac core signals 2-9 than 24,288 1 bits when the hugen signal is deas- serted or greater than 524,288 2 bits when hugen is asserted) late collision (use rtryl to avoid aborting) multiple collisions (greater than 15) transmit underrun larger than normal packet, which is 1518 bytes (see also see the hugen signal description) the tpab signal is also connected to the host. tpdn transmit packet done output when asserted, the tpdn signal indicates successful completion of the packet transmit process. the mac keeps tpdn asserted until the mac receives a fresh request to transmit, which is indicated when the mac control module asserts the tpsf signal. the tpdn sig- nal is also connected to the host. tpsf transmit packet start of frame input the mac control module asserts the tpsf signal to request the E-110 core to transmit a new packet. once asserted, tpsf is kept asserted as long as the hst_tpsf signal from the host is asserted. on a data packet transmit request from the host (hst_tpsf asserted and ctlp deasserted), tpsf is asserted by the mac control module only if pause_active is deas- serted. the mac control module does not enter the pause state because either the pause counter has counted down to zero or the counter is currently loaded with a zero value. if the pause_active signal is asserted, tpsf is not asserted until pause_active is deasserted. if the flowcon_en signal is deasserted, the mac control module does not assert the tpsf signal for host control packet transmit requests. if the flowcon_en signal is deasserted, the tpsf signal is asserted for host data packet transmit requests. when flowcon_en is 1. 24,288 bits = 1518 byte s x 8 bits/byte x 2 (242.88 m s for 100-mbit/s operation or 2.4288 ms for 10-mbit/s operation) 2. 524,288 bits = 32 kbytes x 8 bits/byte x 2 (5242.88 m s for 100-mbit/s operation or 52.43 ms for 10-mbit/s operation)
2-10 signal descriptions asserted, tpsf is asserted one clock after hst_tpsf is asserted for a data or a control packet transmit request. when flowcon_en is deasserted, tpsf is asserted at the same clock as when hst_tpsf is asserted for a data packet request. the mac control module does not interpret the transmit data in any way and transmit data is routed from the host to the E-110 mac directly. trst_l transmit reset output other modules in an asic can use the trst_l signal as a host reset synchronized to the transmit clock (mtxc). because the mtxc clock can be slow with respect to a host reset pulse, or even stopped, the host reset signal (hrst_l) is captured in the E-110 mac transmit func- tion. the transmit function asserts trst_l asynchro- nously to mtxc when the hrst_l signal occurs and deasserts trst_l synchronously on the positive transi- tion of mtxc. modules can use trst_l to initialize transmit logic. the trst_l signal is also connected to the host. 2.1.4 mii to phy signals the signals that interface the mac mii to the phy (not including the miim interface) are listed below. all signals are active high. signal direction is with respect to the mac mii function. see ieee 802.3u standard documentation for further information. the standard ieee mii signal name references are shown in brackets. mcol collision detected input the phy asserts the mcol [col] signal asynchronously with minimum delay from the start of a collision on the media. the phy deasserts mcol to indicate no collision. mcol is internally synchronized to the mtxc clock and in the worst case may take up to two clock cycles to be detected by the mac transmit function. mcrs carrier sense input the phy asserts the mcrs [crs] signal asynchro- nously with minimum propagation delay from the detec- tion of a non-idle medium. the phy deasserts mcrs when it detects an idle medium. the phy also asserts mcrs with minimum propagation delay in response to mtxen [tx_en].
mac core signals 2-11 the phy ensures that mcrs remains asserted through- out the duration of a collision condition. mrxc receive nibble or symbol clock input the mrxc [rx_clk] signal is a continuous clock that provides a timing reference for transfer of the mrxdv [rx_dv], mrxd[3:0] [rxd], and mrxer [rx_er] sig- nals from the phy to the E-110 mac. mrxc is an input from the phy. as long as the phy is receiving a continuous signal from the medium and can recover the mrxc clock reference and supply mrxc, the phy does not need to make a switch from the recovered clock reference to a nominal clock reference (for example, the mtxc [tx_clk] contin- uous clock signal from the phy). however, if the loss of a receive signal causes the phy to lose the recovered clock reference, the phy must source mxrc from a nominal clock reference. if the phy needs to make a switch from recovered clock to nominal clock, it deasserts the mrxdv signal. during the interval between mcrs and the assertion of mrxdv at the beginning of a frame, the phy may extend a cycle of the mrxc clock by holding it in either the high or low condition until the phy has successfully locked onto the recovered clock. successive cycles of mrxc must meet the duty cycle requirement. while mrxdv is asserted, the phy recovers mrxc from the received data. mrxc has a frequency equal to 25% of the data rate of the received signal and is synchronous to recovered data. the duty cycle is between 35% and 60% and is nominally 50%. for 100-mbit/s operation, mrxc is nominally 25 mhz 100 ppm, and the minimum mrxc high and low times are 14 ns. for 10-mbit/s operation, mrxc is nominally 2.5 mhz 100 ppm, and the minimum mrxc high and low times are 140 ns. when the mcrs signal is deasserted, the phy provides mrxc at the phys nominal clock rate (for example, the mtxc clock signal) and with nominal duty cycle. the minimum high and low times are each 35% of the nominal mrxc period except for the transition between recovered clock frequency and nominal clock frequency, which occurs while mrxdv is deasserted. following the transition from mrxdv asserted to mrxdv deasserted,
2-12 signal descriptions the phy can keep mrxc in either the high or low con- dition to extend the mrxc clock by one cycle until the phy is ready to provide mrxc from a nominal clock source. the maximum high or low time for mrxc dur- ing this transition is two times the nominal clock period (a total of 80 ns for 25-mhz operation or 800 ns for 2.5-mhz operation). mrxd[3:0] receive nibble data input mrxd[3:0] [rxd] consists of four data signals that the phy drives synchronously to the rising edge of the mrxc clock. for each mrxc period in which mrxdv is asserted, the phy transfers four bits of data over the mrxd[3:0] signals to the E-110 mac. mrxd[0] is the least signi?cant bit. when mrxdv is deasserted, the mrxd[3:0] signals have no effect on the E-110 mac. for a frame to be correctly interpreted by the E-110 mac, a completely formed sfd must be passed across the interface. a completely formed sfd is the octet 0b1010.1011, which follows seven identical octets of pre- amble (0b1010.1010). mrxdv receive data valid input the phy asserts the mrxdv [rx_dv] signal to indicate that the phy is presenting recovered and decoded nib- bles on the mrxd[3:0] [rxd[3:0]] signals and that mrxc is synchronous to the recovered data. the phy asserts mrxdv synchronously to the rising edge of mrxc. the phy keeps mrxdv asserted from the ?rst recovered nib- ble of the frame through the ?nal recovered nibble and deasserts it prior to the ?rst mrxc that follows the ?nal nibble. mrxdv encompasses the frame, starting no later than the sfd and excluding any end of frame delimiter . the phy may also assert mrxdv for transferring a validly decoded preamble. mrxer receive error input the phy asserts the mrxer [rx_er] signal to indicate to the E-110 mac that a media error (for example, a coding error) was detected somewhere in the frame pres- ently being transferred from the phy to the E-110 mac. the phy asserts mrxer synchronously to the rising edge of mrxc for one or more mrxc periods and then
mac core signals 2-13 deasserts it. the phy must assert mrxer for at least one mrxc clock period during the frame. mtxc transmit nibble or symbol clock input the mtxc [tx_clk] signal operates at a frequency of 25 or 2.5 mhz. mtxc is a continuous clock that provides a timing reference for transfer of the mtxen [tx_en], mtxd[3:0] [txd[3:0]], and mtxer [tx_er] signals from the E-110 mac to the phy. the phy provides mtxc. the mtxc frequency is 25% of the transmit data rate. a phy operating at 100 mbit/s provides an mtxc fre- quency of 25 mhz 100 ppm. a phy operating at 10 mbit/s provides a tx_clk frequency of 2.5 mhz 100 ppm. the duty cycle of the tx_clk signal is between 35% and 60%, inclusively. mtxd[3:0] transmit nibble data output the mtxd[3:0] signals are synchronous to the rising edge of mtxc. mtxd[3:0] [txd[3:0]] consists of four data signals that are synchronous to mtxc. for each mtxc period in which mtxen is asserted, the phy accepts the mtxd[3:0] signals for transmission. mtxd[0] is the least signi?cant bit. when mtxen is deasserted, the mtxd[3:0] signals have no effect on the phy. mtxen transmit enable output the mtxen [tx_en] signal indicates that the E-110 mac is presenting mtxd[3:0] nibbles on the mii for transmission. the mac asserts mtxen synchronously with the ?rst nibble of the preamble. mtxen remains asserted while all nibbles to be transmitted are presented to the mii. the mac deasserts mtxen prior to the ?rst mtxc following the ?nal nibble of a frame. mtxen is synchronous to the rising edge of mtxc, and the phy samples mtxen synchronously. mtxer transmit coding error output the E-110 mac function asserts the mtxer [tx_er] signal synchronously to the rising edge of mtxc, and the phy samples mtxer synchronously. when the mac asserts mtxer for one mtxc clock period while mtxen is also asserted, mtxer causes the phy to transmit one or more symbols that are not part of the valid data or
2-14 signal descriptions delimiter set somewhere in the frame being transmitted to indicate that there has been a transmit coding error. if the mac asserts the mtxer signal when a phy is operating at 10 mbit/s or when mtxen is deasserted, the phy must not allow the transmission of data to be affected. 2.1.5 host control signals the control lines from the host to the mac core are listed below. all signals are active high unless otherwise indicated. signal direction is with respect to the mac function. these signals are not synchronized on a packet boundary within the E-110 mac. that is, any change in these signals is immediate, and changing the state of the signals during a packet can cause unexpected results. bkoff_limit[1:0] backoff limit input the bkoff_limit[1:0] signals determine the number of transmission attempts the E-110 mac core makes after a collision and the integer number of slot times 1 the core waits before rescheduling a transmission attempt (during retries after a collision). when a transmission attempt has terminated due to a collision, the mac core retries until either the transmis- sion is successful or the maximum number of attempts (16) have been made and all have terminated due to collisions.the mac core waits an integer number of slot times (backoff) before each attempt to retransmit. the backoff delay, r , before each retransmission attempt is chosen as a uniformly distributed random integer in the range: the variable k is the retry counter value and is calculated as follows: the variable n is the current number of retransmissions. the retry counter value is held to the lesser of the current number of retransmissions or the value 10. 1. one slot time equals 512 bit times. 0 r 2 k < kminn 10 , ? =
mac core signals 2-15 the following table illustrates the relationship between the backoff delay and the maximum retry counter value. as an example, if the bkoff_limit[1:0] value is 0b10, the maximum retry counter value is 4. the E-110 mac core retry counter value is zero before any collisions occur. when a collision occurs, the retry counter incre- ments to one, and the backoff delay is set to a value between 0 and 1 slot times. when the backoff delay expires, another transmission attempt is made. if a colli- sion occurs again, the retry counter goes to two and the backoff delay is set to between 0 and 3. assuming a col- lision at each attempt, the process continues until the retry counter reaches four, at which time the backoff delay is set to between 0 and 15, and the retry counter rolls over to zero. if the next attempt also encounters a collision, the retry counter increments to one, and the backoff value is set to between 0 and 1. if collisions keep occurring, the mac core keeps retrying for a total of 16 retransmission attempts and then stops retrying. the fol- lowing table summarizes the transmission retry algorithm for all four cases of bkoff_limit[1:0]. bkoff_limit maximum backoff delay in slot times retry counter (k) maximum value 10 00 0C1023 10 01 0C255 8 10 0C15 4 11 0C1 1
2-16 signal descriptions the host must assert the bkoff_limit[1:0] signals syn- chronously with the rising edge of mtxc clock. the effect of these signals is not synchronized on a packet bound- ary within the E-110 core and changing the state of the signals during a packet transmission can cause unex- pected results. crcen crc append enable input the host asserts the crcen signal to instruct the trans- mit function to append the fcs calculated by the mac to the end of the transmitted data. when the host deasserts crcen, the E-110 core still calculates the fcs of the transmitted packet data, but allows the fcs that comes from the host to be transmitted with the packet. the E-110 core checks the host-generated fcs to see if it is valid except when the host asserts the nopre signal (see the nopre no preamble input signal description on page 2-20). if the fcs is not valid, the E-110 core asserts the fcs error signal (tsv21) in the transmit statistics vector. crcen is synchronous with the rising edge of the mtxc clock and may be changed when the table 2.1 transmission retry algorithm for bkoff_limit[1:0] (maximum k = 10, 8, 4, 1) attempt 12345678 9 10111213141516 current k (maximum = 10) 12345678 9 10101010101010 backoff delay 0C1 0C3 0C7 0C15 0C31 0C63 0C127 0C255 0C1023 0C1023 0C1023 0C1023 0C1023 0C1023 0C1023 0C1023 current k (maximum = 8) 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 backoff delay 0C1 0C3 0C7 0C15 0C31 0C63 0C127 0C255 0C1 0C3 0C7 0C15 0C31 0C63 0C127 0C255 current k (maximum = 4) 1234123412341234 backoff delay 0C1 0C3 0C7 0C15 0C1 0C3 0C7 0C15 0C1 0C3 0C7 0C15 0C1 0C3 0C7 0C15 current k (maximum = 1) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 backoff delay 0C1 0C1 0C1 0C1 0C1 0C1 0C1 0C1 0C1 0C1 0C1 0C1 0C1 0C1 0C1 0C1
mac core signals 2-17 transmit engine is idle (either during reset or when no packet is being transmitted). fls_crs false carrier sense (backpressure control) input the host may use the E-110 core fls_crs input pin to implement backpressure (see section 1.4.6, mac back- pressure feature, on page 1-22). backpressure makes the medium look busy to other stations on the network who wish to send data to the E-110 core. the host asserts the fls_crs input when a congestion threshold for the ports input buffer is reached. the host should select the congestion threshold in such a way that it leaves enough room in the buffer for the frame in progress. when the fls_crs pin is asserted, the E-110 core waits until 44 bit times after the medium becomes inactive (crs deasserted) and then starts sending out a false carrier data pattern (alternate ones and zeroes). the E-110 core continues sending this data pattern as long as the host continues to assert the fls_crs signal. if the E-110 core is already sending out normal packet data on the mii, assertion of the fls_crs pin only goes into effect after the current transmission is completed. if the E-110 core is already sending out a false carrier data pattern on the mii, any transmit requests from the host are kept pending until the fls_crs pin is deasserted. it is the responsibility of the host to disable the jabber timer if the E-110 core is being used in the 10base-t mode and if the fls_crs pin is asserted for more than 20 ms. the E-110 core ignores collisions during transmission of data while the fls_crs pin is asserted. standard man- agement information related to the ethernet interface is not affected by the fls_crs signal. fulld full-duplex control input when the host asserts the fulld signal, the transmit function operates in full-duplex mode, does not defer to the crs signal, and does not respond to the col signal. when fulld is deasserted, the transmit function oper- ates in half-duplex mode. in half-duplex mode, the E-110 core defers to crs and responds to col. fulld may be changed when the system is idle (either during reset or when both transmit and receive engines are idle). the host must assert fulld synchronously to the rising edge of mtxc.
2-18 signal descriptions hrst_l host reset input the hrst_l signal is an active low signal that initial- izes the mac function and the miim function when the host asserts it. when hrst_l is asserted, the mac asserts the synchronized transmit and receive reset sig- nals, trst_l and rrst_l, which are inputs to the mac transmit function and receive function, respectively. other modules in an asic may use these signals for initializa- tion. both trst_l and rrst_l are asserted low asyn- chronously when hrst_l occurs and are deasserted synchronously with their respective clocks (trst_l with mtxc and rrst_l with mrxc). the mac assumes that hrst_l is asynchronous to all clocks. the minimum reset width is 400 ns for the 100-mbit/s mode of operation and 4000 ns for the 10-mbit/s mode. hugen huge packet enable input a packet consists of the following ?elds: destination address (six bytes), source address (six bytes), data length (two bytes), data (the 802.3 standard stipulates a maximum of 1500 bytes), and frame check sequence (four bytes). a packet can therefore be up to 1518 bytes and meet the 802.3 standard requirements. however, as applications have evolved over a period of time, it is required that mac controllers have the ?exibility to transmit and receive packets of various sizes (in addi- tion to supporting the conventional maximum packet sizes speci?ed by the 802.3 standard). when asserted, the hugen signal indicates to the trans- mit function in the E-110 core to allow transmission of packets up to 32 kbytes. the E-110 core truncates any data packet larger than 32 kbytes. assertion of the hugen signal also instructs the receive function to receive packets up to 32 kbytes. when hugen is asserted, the excess deferral value is changed to 131,072 nibble clocks (524,288 bit times, or two times the maximum packet size bit times). tsv[15:0] and rsv[15:0] re?ect the count of number of bytes transmit- ted or received. when hugen is deasserted, the maxi- mum size packet supported by the E-110 core is 1518 bytes. (note that excess deferral is different this time as the packet size changes.)
mac core signals 2-19 when the mac transmits a packet, the mac truncates any data beyond 1536 bytes (when hugen is deas- serted) or 32 kbytes (when hugen is asserted) and asserts the tsv26 signal (see section 2.1.6, statistics vector to host signals, on page 2-21), which indicates that the packet was aborted because of excessive length. note that the mac does not begin truncating the data immediately after 1518 bytes. when the mac receives a packet longer than 1518 bytes (with hugen deasserted), or 32 kbytes (with hugen asserted), the mac asserts the rsv23 signal (see sec- tion 2.1.6, statistics vector to host signals), which indi- cates that a bad packet has been received. however, the mac continues to accept bytes until 1536 bytes or 32 kbytes, beyond which it stops accepting bytes. ipgr1[6:0] non back-to-back ipg (part 1) input the ipgr1[6:0] signals contain the programmable trans- mit interpacket gap (ipg) for non back-to-back transmits, part 1. non back-to-back transmits allow a receive to occur between transmits. the mac core samples the ipgr1[6:0] signals synchronously with the rising edge of the mtxc clock during reset. for a detailed discussion of the ipgr1[6:0] signals, see ipg half-duplex operation on page 3-6. ipgr2[6:0] non back-to-back ipg (part 2) input the ipgr2[6:0] signals contain the programmable trans- mit ipg for non back-to-back transmits, part 2. the mac core samples the ipgr2[6:0] signals synchronously with the rising edge of the mtxc clock during reset. for a detailed discussion of ipgr2[6:0], see ipg half-duplex operation and ipg full-duplex operation on page 3-6. ipgt[6:0] back-to-back ipg input the ipgt[6:0] signals contain the programmable transmit ipg for back-to-back transmits. nominal operation requires that ipgt[6:0] have a value of 18. for a detailed discussion of ipgt[6:0], see ipg half-duplex operation on page 3-6. the mac core samples the ipgt[6:0] signals synchro- nously with the rising edge of the mtxc clock during reset. for a detailed discussion of ipgt[6:0], see ipg
2-20 signal descriptions half-duplex operation and ipg full-duplex operation on page 3-8. nopre no preamble input when asserted, the nopre signal instructs the transmit function to disable the addition of the preamble. padding and fcs appending are also disabled when nopre is asserted. nopre is synchronous with the rising edge of the mtxc clock and may be changed when the transmit engine is idle (either during reset or when no packet is being transmitted). when deasserted, the nopre signal allows the transmit function to add the preamble, perform byte padding, and do fcs appending. paden pad enable input the paden signal, when asserted, instructs the transmit function to pad packets of fewer than 60 bytes with a suf- ?cient number of bytes of zero such that the minimum packet size (64 bytes, including data plus an fcs of 4 bytes) speci?ed by ieee 802.3 is maintained. when deasserted, paden disables the padding of packets. for padding to take place, both paden and crcen must be asserted. paden is synchronous with the rising edge of the mtxc clock and may be asserted or deasserted when the transmit engine is idle (either during reset or when no packet is being transmitted). rtryl retry late collision input the rtryl signal, when asserted, instructs the transmit function to retry transmission after a late collision (a col- lision that occurs after 512 bit times into the packet) instead of aborting it. when deasserted, retryl instructs the E-110 core not to retry a transmission after a late collision, to reset the retry counter, and to abort the transmit attempt. for normal collisions (a collision that occurs fewer than 512 bit times into the packet) the transmit function retries the transmission up to 15 times before aborting. if late collisions occur frequently, it may indicate that there is a problem with the network cabling or equipment. the tsv29 signal (see section 2.1.6, statistics vector to host signals, on page 2-21) in the transmit statistics vector, when asserted, indicates the transmission was dropped because of a late collision.
mac core signals 2-21 rtryl is synchronous with the rising edge of mtxc and may be asserted or deasserted when the transmit engine is idle (either during reset or when no packet is being transmitted). tboff_sel stop backoff input the tboff_sel input signal controls whether or not the E-110 core uses the binary exponential backoff algorithm during collisions. if the tboff_sel signal is asserted, the E-110 core transmits a jam pattern after a collision and tries to retransmit after timing out for the ipg value. in this case, the binary exponential backoff algorithm is not used. if the tboff_sel signal is deasserted, the E-110 core implements the binary exponential backoff algorithm. the E-110 core stops sending packet data, sends a jam pat- tern, and tries to transmit again. the amount of time the E-110 core waits between successive retries is 512 bit times 1 x r, where r is a random integer between 0 and 2 k - 1. k is the retry counter value, which can range from 1 to 10. the host must change the tboff_sel signal synchro- nously with the rising edge of mtxc clock. the effect of this signal is not synchronized on a packet boundary within the E-110 core, so changing the state of the signal during a packet transmission can cause unexpected results. 2.1.6 statistics vector to host signals the statistics vector signal lines from the mac are listed below. all signals are active high unless otherwise indicated. signal direction is with respect to the mac. rsv[25:0] receive statistics vector output the rsv[25:0] signals contain the receive statistics vec- tor and are updated on the falling edge of rsvp_l. the statistics vector is issued at the end of any minimally quali?ed receive event . a minimally quali?ed receive event occurs when the mac receives at least one nibble of data beyond a valid preamble and sfd. 1. 512 bit times equals one slot time.
2-22 signal descriptions the rsv[25:0] signals are stable until the subsequent rsvp_l pulse. the condition associated with each signal is valid when the signal is high. the receive statistics provided by the mac function can be used for rmon (remote monitoring) and snmp (sim- ple network management protocol). however, the mac does not collect the statistics speci?cally mentioned in the rmon and snmp speci?cations. the mac provides basic per packet information that can be collected by an application built on top of the mac. the collected infor- mation can then be used for rmon and snmp. the signals in rsv[25:0] have the following functions: rsv25 carrier event previously seen. when the mac asserts the rsv25 signal, it indicates that at some time since the last receive vector a carrier was detected, noted, and reported with this vec- tor. the carrier event is not associated with this packet. a carrier event is de?ned as activity on the receive channel that does not result in a packet receive attempt . an example would be receiving a preamble but no sfd, or receiving more than seven octets of preamble. a carrier event can occur in either full- or half-duplex modes. if rsv25 is deasserted, a carrier was not detected. rsv24 good packet received. for 100-mbit/s operation, a good packet has no 4b/5b receive code-group violations, no dribble nibbles, a valid fcs, and a proper packet length (at least 64 bytes but not more than 1518 bytes or 32 kbytes). 4b/5b code- group violations include the following: 0b00100, 0b00000, 0b00001, 0b00010, 0b00011, 0b00101, 0b00110, 0b01000, 0b01100, 0b10000, and 0b11001. for 10-mbit/s operation, a good packet has no dribble nibbles , a valid fcs, and a proper packet length (at least 64 bytes but not more than 1518 bytes or 32 kbytes).
mac core signals 2-23 rsv23 bad packet received. for 100-mbit/s operation, a bad packet contains at least one of the following problems: 4b/5b code violations, dribble nibbles, bad fcs, less than 64 bytes (short packet), or more than 1518 bytes or 32 kbytes (long packet). for 10-mbit/s operation, a bad packet contains at least one of the following problems: dribble nibbles, a bad fcs, less than 64 bytes (short packet), or more than 1518 bytes or 32 kbytes (long packet). rsv22 long event previously seen. when the mac asserts the rsv22 signal, it indicates that at some time since the last receive vector a long event was detected, noted, and reported with this vector. the long event is not associated with this packet. a long event is activity on the network in excess of 50,000 bit times. a long event is not detected in full-duplex mode. if rsv22 is deasserted, it indicates that a long event was not seen. rsv21 invalid preamble content (not 55h) or code (0x50555) seen in the last reception. rsv20 broadcast packet received (all ones in the destination address ?eld). rsv19 multicast packet received. (the ?rst bit in the destination address ?eld, which is also the least signi?cant bit, is equal to a onethe least signif- icant bit is transmitted ?rst.) rsv18 fcs error detected in the received packet. the fcs bytes in the received packet do not match those the mac calculates at the destination while the packet is being received. rsv17 dribble nibble seen in the received packet. each byte consists of two nibbles, so the number of received nibbles should always be even. if there is an odd number of nibbles, the last nibble is the dribble nibble. rsv16 receive code violation detected. there is a 4b/5b code violation. see the rsv24 signal description for a de?nition of code-group viola- tions. the phy asserts mrxer whenever a receive code-group violation occurs.
2-24 signal descriptions tsv[30:0] transmit statistics vector output the tsv[30:0] signals contain the transmit statistics infor- mation. the mac function updates the tsv[30:0] signals on the falling edge of the tsvp_l signal. the mac issues the statistics vector at the end of the ?nal or only attempt to transmit each packet, whether the packet is transmitted or not. the tsv[30:0] signals are stable until the subsequent tsvp_l pulse. the condition associated with each signal is valid when the signal is high. the mac function provides transmit statistics that can be used for rmon and snmp. however, the mac does not collect the statistics speci?cally mentioned in the rmon rsv15 (msb) packet length bit 15. if the host asserts the hugen signal, the packet length (source address, destination address, data length, data, and fcs ?elds) as indicated by the packet length bits can be up to 32 kbytes. bits 15 through 0 form a 16-bit binary counter, with the least signi?cant bit (rsv0) = 1 byte. rsv14 packet length bit 14. rsv13 packet length bit 13. rsv12 packet length bit 12. rsv11 packet length bit 11. rsv10 packet length bit 10. rsv9 packet length bit 9. rsv8 packet length bit 8. rsv7 packet length bit 7. rsv6 packet length bit 6. rsv5 packet length bit 5. rsv4 packet length bit 4. rsv3 packet length bit 3. rsv2 packet length bit 2. rsv1 packet length bit 1. rsv0 (lsb) packet length bit 0.
mac core signals 2-25 and snmp speci?cations. the mac provides basic per packet information that can be collected by an application built on top of the mac. the collected information can then be used for rmon and snmp. the signals in tsv[30:0] have the following functions: tsv30 transmit canceled because of excess deferral. excess deferrals occur when the network is con- stantly busy (greater than 24,288 bit times when hugen is deasserted or greater than 524,288 bit times when hugen is asserted). tsv29 transmit dropped because of late collision. a late collision is one that occurs greater than 512 bit times into packet transmission. tsv28 transmit dropped because of excessive collisions (15 transmit retries). tsv27 transmit aborted because of underrun. if the host is unable to supply transmit packet data bytes in a timely manner to the E-110 core an underrun condition exists. tsv26 transmit aborted because of excessive length. the transmission is aborted if the packet exceeds 1518 bytes with the hugen signal low, or 32 kbytes with the hugen signal high. tsv25 packet transmitted successfully. tsv24 packet deferred on transmission attempt. a packet is deferred when the network is busy. tsv23 broadcast packet transmitted or attempted. tsv22 multicast packet transmitted or attempted. tsv21 fcs error seen on transmission attempt. when the host deasserts crcen, indicating that the host provides the fcs ?eld in transmitted packets, the mac veri?es the host fcs against its inter- nally computed fcs. the E-110 core asserts the tsv21 signal to indicate a mismatch in the two fcss. if the host asserts the crcen signal, the mac both calculates and provides the fcs in transmitted packets. in this case, the mac does not assert the tsv21 signal. tsv20 late collision (a collision that occurs more than 512 bits times into the packet) seen on transmis- sion attempt.
2-26 signal descriptions tsvp_l transmit statistics vector pulse output the tsvp_l signal is active low. when asserted, it indi- cates that the tsv[30:0] signals have been updated with tsv19 (msb) collision count bit 3. the collision count can range from 0 to 15 for a packet ultimately transmitted, but can never be 16. after 15 retries, the packet is dropped because of excessive collisions. bits 3 through 0 form a 4-bit binary counter, with the least signi?cant bit = 1 collision. tsv18 collision count bit 2. tsv17 collision count bit 1. tsv16 (lsb) collision count bit 0. tsv15 (msb) packet length bit 15. the packet length bits indi- cate the length of the packet in bytes. the packet includes the source address, destination address, data length, data, and fcs ?elds. bits 15 through 0 form a 16-bit binary counter, with the least signi?cant bit (tsv0) = 1 byte. tsv14 packet length bit 14. tsv13 packet length bit 13. tsv12 packet length bit 12. tsv11 packet length bit 11. tsv10 packet length bit 10. tsv9 packet length bit 9. tsv8 packet length bit 8. tsv7 packet length bit 7. tsv6 packet length bit 6. tsv5 packet length bit 5. tsv4 packet length bit 4. tsv3 packet length bit 3. tsv2 packet length bit 2. tsv1 packet length bit 1. tsv0 (lsb) packet length bit 0.
mac core signals 2-27 a new transmit statistics vector. when deasserted, it indi- cates that there has been no update. 2.1.7 random number generator to host signals below is a list of the signals that interface the E-110 mac random number generator function to the host. all signals are active high unless otherwise noted. signal direction is with respect to the random number generator. hwd[10:0] host write data [10:0] input the hwd[10:0] signals contain the value of the random number that the host loads into the macs linear feed- back shift register (lfsr) to generate the random num- ber sequence used in collision backoff timing. hwd[10:0] must remain stable for two mtxc cycles after lrng is asserted. lrng load random number generator input the host asserts the lrng signal to indicate that the hwd[10:0] signals are valid and the mac function should latch them. when the host deasserts lrng, the hwd[10:0] signals are not valid. lrng must be synchro- nous to the mtxc clock and at least one mtxc clock cycle wide, which is 40 ns for 100-mhz operation and 400 ns for 10-mhz operation (see the description of the mtxc signal on page 2-13). the hwd[10:0] signals must be stable when the host pulses lrng. 2.1.8 scan test signals the mac design uses full scan test methodology, which consists of a single scan chain and appropriate scan signals. the scan signals are described below. tmode test mode input when the tmode signal is asserted, the mac switches to test mode. when tmode is deasserted, the mac resumes normal functional operation. test_se scan enable input when the test_se signal is asserted, all of the registers in the mac accept data from their test inputs instead of from their normal inputs. when test_se is asserted, the
2-28 signal descriptions scan data can be shifted in on the test_si pin. test_se must be kept deasserted during normal operation. test_si scan input input the test_si signal is the serial scan chain input pin. when the tmode and test_se signals are asserted, test data can be presented to the mac on the test_si pin. test_so scan output output the test_so signal is the serial scan chain output pin. the data presented on test_so is the output data that results from the input stimulus on test_si. 2.2 mac control module signals the interface diagram for the optional mac control module core is shown in figure 2.2. the signals fall into the following groups: E-110 mac core signals phy host signals figure 2.2 mac control module core interface diagram rpsf mrxc tpdn rrst_l rpef trst_l tpsf rpd[7:0] E-110 rpdv rsv_good tpab mac control module flowcon_en pause_mirror[23:0] ctlp hst_tpsf rcv_load_dly[3:0] unsupp_opcode rsvd_pausef pause_time_in[15:0] pause_rsvp_l rcvng_pause_frame addr_match pause_active xmt_pausef signals host signals mtxc phy signals mac core core
mac control module signals 2-29 2.2.1 mac control module to E-110 core signals the signals that connect the optional mac control module to the E-110 core are listed below (see also section 2.1.3, mac control module signals (optional), on page 2-7). all signals are active high unless otherwise indicated. signal direction is with respect to the mac control module. rpd[7:0] receive packet data input the rpd[7:0] signals are the receive data bus. the sig- nals hold the received data byte for two mrxc clock cycles. rpdv receive packet data valid input a packet transmission from the receive function begins when the receive function asserts the rpsf and rpdv signal at the ?rst byte of received packet data on rpd[7:0] after removing the preamble and sfd. for sub- sequent data bytes, the receive function asserts only the rpdv signal until the last byte, when it asserts both rpdv and rpef. rpef receive packet end of frame input the mac asserts the rpef signal for one mrxc clock cycle to indicate that the last byte of the receive packet is available to the mac control module on rpd[7:0]. rpsf receive packet start of frame input the mac asserts the rpsf signal for one mrxc clock cycle to indicate that the ?rst byte of a receive packet is available to the mac control module on rpd[7:0]. rrst_l receive reset input other modules in an asic can use the rrst_l signal as a host reset synchronized to the receive clock (mrxc). because the mrxc clock can be slow with respect to a host reset pulse, or even stopped, the host reset signal (hrst_l) is captured in the E-110 mac receive function, which asserts rrst_l asynchronously to mrxc when hrst_l occurs and deasserts rrst_l synchronously on the positive transition of mrxc. rsv_good receive statistics vector good input at the end of a receive frame, the mac updates the receive statistics vector (rsv[25:0]). the mac asserts
2-30 signal descriptions the rsv_good signal, which re?ects the rsv24 bit, if the received frame has no errors. the mac deasserts the signal if the received frame contains errors. tpab transmit packet abort input when asserted, the tpab signal indicates that the trans- mission was discontinued. tpab remains asserted until the E-110 mac function receives a request to transmit, which is indicated when the mac control module asserts tpsf. when deasserted, tpab indicates that the trans- mission was not aborted. the following circumstances cause the transmission to be halted: excess deferrals, which occur when the media is busy longer than twice the maximum frame length (greater than 24,288 1 bits when the hugen signal is deas- serted or greater than 524,288 2 bits when hugen is asserted) late collision (use rtryl to avoid aborting) multiple collisions (greater than 15) transmit underrun larger than normal packet, which is 1518 bytes (see also see the hugen signal description) tpdn transmit packet done input the E-110 core asserts the tpdn signal after successful transmission of a packet. tpdn is asserted until a new tpsf signal is asserted by the mac control module. when the E-110 asserts tpdn, the mac control module goes back to the idle state. the tpdn signal is synchro- nous to mtxc. tpsf transmit packet start of frame output the mac control module asserts the tpsf signal to request the E-110 core to transmit a new packet. once asserted, tpsf is kept asserted as long as the hst_tpsf signal from the host is asserted. on a data packet transmit request from the host (hst_tpsf asserted and ctlp deasserted), tpsf is asserted by the 1. 24,288 bits = 1518 byte s x 8 bits/byte x 2 (242.88 m s for 100-mbit/s operation or 2.4288 ms for 10-mbit/s operation) 2. 524,288 bits = 32 kbytes x 8 bits/byte x 2 (5242.88 m s for 100-mbit/s operation or 52.43 ms for 10-mbit/s operation)
mac control module signals 2-31 mac control module only if pause_active is deas- serted. the mac control module does not enter the pause state because either the pause counter has counted down to zero or the counter is currently loaded with a zero value. if the pause_active signal is asserted, tpsf is not generated until pause_active is deasserted. if the flowcon_en signal is deasserted, the mac con- trol module does not assert the tpsf signal for host con- trol packet transmit requests. if the flowcon_en signal is deasserted, the tpsf signal is asserted for host data packet transmit requests. when flowcon_en is asserted, tpsf is asserted one clock after hst_tpsf is asserted for a data or a control packet transmit request. when flowcon_en is deasserted, tpsf is asserted at the same clock as when hst_tpsf is asserted for a data packet request. the mac control module does not interpret the transmit data in any way and transmit data is routed from the host to the E-110 mac directly. trst_l transmit reset input other modules in an asic can use the trst_l signal as a host reset synchronized to the transmit clock (mtxc). because the mtxc clock can be slow with respect to a host reset pulse, or even stopped, the host reset signal (hrst_l) is captured in the E-110 mac transmit func- tion. the transmit function asserts trst_l asynchro- nously to mtxc when the hrst_l signal occurs and deasserts trst_l synchronously on the positive transi- tion of mtxc. modules can use trst_l to initialize transmit logic. 2.2.2 mac control module to phy signals the signals between the phy and the mac control module are listed below. signal direction is with respect to the mac control module. mrxc receive nibble or symbol clock input the mrxc clock is a continuous clock signal that oper- ates at 25 mhz or 2.5 mhz and provides a timing refer- ence for data transfers from the E-110 core to the mac control module.
2-32 signal descriptions mtxc transmit nibble or symbol clock input the mtxc clock is a continuous clock signal that oper- ates at 25 mhz or 2.5 mhz and provides a timing refer- ence for data transfers from the mac control module to the E-110 core. 2.2.3 mac control module to host signals the signals that connect the mac control module to the host are listed below. all signals are active high unless otherwise indicated. signal direction is with respect to the mac control module. addr_match unicast address match input when asserted the addr_match signal indicates to the mac control module that the destination address of a pause frame matched the unicast address of the E-110 mac core. the addr_match signal should be asserted at least two clocks before the type ?eld is presented on the host receive interface. this signal is synchronous to mrxc. ctlp host control packet transmit request input when asserted, the ctlp signal informs the mac control module to treat a host packet transmit request (hst_tpsf asserted) as a pause frame transmit request. when the ctlp signal is deasserted, the mac control module treats the host packet transmit request as a data packet request. the ctlp signal is synchronous to mtxc. flowcon_en flow control enable input when this pin is deasserted: no action is taken to load the pause time and the pause_timer is reset. the receive state machine stays in the idle state. if the host requests to transmit a control packet, the request is ignored. if the host requests to transmit a data packet, the tpsf signal is asserted at the same clock as the hst_tpsf signal and the mac control module is transparent to the host and E-110 mac core.
mac control module signals 2-33 the host must assert the flowcon_en signal synchro- nously with the rising edge of the mtxc clock before transmission begins. the flowcon_en signal is static and must not be used to recon?gure the logic on the ?y. the effect of this signal is not synchronized on a packet boundary within the E-110 control module and changing the state of this signal during a packet transmission can cause unexpected results. hst_tpsf host packet transmit request input the host interface asserts the hst_tpsf signal to request the mac control module to transmit a new packet. the host must keep the hst_tpsf signal asserted for one transmit clock period after the E-110 core asserts the tpud signal. the hst_tpsf signal is synchronous to mtxc. pause_active pause in progress output when asserted the pause_active signal indicates to the host that the mac control module is in the pause state and cannot transmit any data frames. the pause_active signal is synchronous to mrxc. pause_mirror[23:0] mirror counters value output the pause_mirror[23:0] signals contain the counter bits that re?ect the value of the receivers pause timer. the pause_mirror[23:0] signals are valid after the mac control module core asserts the xmt_pausef signal. pause_rsvp_l comprehensive receive statistics vector pulse output on the falling edge of the pause_rsvp_l signal, the rsvd_pausef and unsupp_opcode signals are valid. rcv_load_dly[3:0] receiver delay in loading transmitted pause input the 4-bit value contained in the rcv_load_dly[3:0] signals are in terms of slot times and accounts for the total time a receiver takes to load the transmitted pause value into its own pause counter. the 4-bit value is
2-34 signal descriptions loaded into the mirror counter when the hst_tpsf and ctlp signals are asserted. the mac control module adds the 4-bit value to the pause_time_in[15:0] value in order to synchronize with a receivers pause timer. the rcv_load_dly[3:0] signals must be stable before the ctlp signal is asserted. rcvng_pause_frame receiving pause frame output this signal is asserted by the mac control module to indi- cate to the host that a pause frame has been received. this helps host to ?lter pause frames, if required. the mac control module asserts the rcvng_pause_frame signal two clocks after the opcode ?eld is presented on the receive data bus during valid reception of a pause frame (provided that the address, type, and opcode ?eld match ?ags are set). once asserted, this signal is held asserted until the completion of valid reception of a pause frame. this signal is synchronous to mrxc. rsvd_pausef received pause frame output the rsvd_pausef signal, when asserted, indicates that the current packet received is a valid pause frame. the mac control module core deasserts the signal if a data packet is received. this signal is valid on the falling edge of pause_rsvp_l. pause_time_in[15:0] transmitted pause time input the pause_time_in[15:0] signals constitute the 16-bit pause time value (in slot times) sent in the transmit con- trol packet. the mac control module loads the 16-bit value into its mirror counter when the hst_tpsf and ctlp signals are asserted. the pa use_time_in[15:0] sig- nals must be stable before the ctlp signal is asserted. unsupp_opcode unsupported opcode output the mac control module asserts the unsupp_opcode signal if any opcode other than the pause opcode is received in a valid control frame. this signal is valid on the falling edge of pause_rsvp_l.
miim core signals 2-35 xmt_pausef transmitted pause frame output the xmt_pausef vector signal is asserted after the transmission of a pause frame. it is deasserted if a data packet is transmitted. this signal is valid on the falling edge of the tsvp_l signal, which is asserted by the E-110 core. 2.3 miim core signals the interface diagram for the optional miim core is shown in figure 2.3. figure 2.3 miim core interface diagram 2.3.1 miim core to host signals the signals that connect the miim core to the host are listed below. all signals are active high unless otherwise indicated. signal direction is with respect to the miim core. busy busy output the miim core asserts the busy signal to indicate to the host that a read, write, or scan operation is in progress. busy is deasserted when no mii operation is in progress. mii ctld[15:0] fiad[4:0] rgad[4:0] lctld rstat scan busy prsd[15:0] miilf nvalid mii to host signals management core management core mdo mdi mdoen mii to phy signals management core mdc clks hclk hrst_l
2-36 signal descriptions if a read, write, or scan command is issued while the busy signal is asserted, the results are unpredictable. clks clock select input the host asserts the clks signal to indicate that the hclk signal is 33 mhz. when deasserted, it informs the miim that hclk is 25 mhz. the miim uses clks to determine how to divide down hclk to create the mdc signal (see the hrst_l host reset input signal description on page 2-18). the host must assert clks synchronously to the rising edge of hclk, because clks is used in the clock divider circuit, which runs on hclk. ctld[15:0] control data [15:0] input the host places data to be written to the mii phy on the ctld[15:0] control data bus. after the host asserts the lctld signal, the host must observe the busy signal and keep the ctld[15:0] signals valid until the miim core deasserts the busy signal. the host uses the ctld[15:0] signals to write the control register of a phy. for a defini- tion of the control register, see the subsection entitled write phy control register on page 3-19. fiad[4:0] phy address [4:0] input the fiad[4:0] signals contain the address of the phy the host has selected for reading or writing. the host must not change the fiad[4:0] signals while the miim core is asserting the busy signal; otherwise, the miim core may read the fiad[4:0] signals incorrectly. the miim core can support up to 32 phys. hclk host clock input the host clock is either a 33-mhz or 25-mhz clock. the clks signal indicates the hclk frequency to the miim. the host clock generates the miim data clock (mdc), which has minimum high and low times of 200 ns each. a 33-mhz hclk is divided by 14 to generate a 2.35 mhz mdc and a 25-mhz hclk is divided by 10 to generate a 2.5 mhz clock. to meet the minimum high and low times, the maximum frequency of mdc is 2.5 mhz.
miim core signals 2-37 hrst_l host reset input the hrst_l signal is an active low signal that initial- izes the mac function and the miim function when the host asserts it. lctld load control data input the host asserts the lctld signal to indicate that the miim core may begin an mii write sequence. when the host asserts lctld, the host must ensure that the ctld[15:0], fiad[4:0], and rgad[4:0] signals are valid and must not change them during the entire mii write oper- ation. the miim core requires that the lctld signal be at least one hclk pulse wide, which is 30.3 ns for a 33-mhz hclk or 40 ns for a 25-mhz hclk (see the hclk signal description on page 2-18). lctld must be asserted and deasserted synchronously with the rising edge of hclk. miilf mii link failure output when the host uses the miim core to read a phys status register, the miilf output signal from the miim core re?ects the state of the link status bit (bit 2) in the phys mii status register (see table 3.3 on page 3-21); that is, if the link status bit is one, miilf is asserted, indicating a link pass . if the bit is zero, miilf is deasserted. the miim core updates the miilf signal whenever a sta- tus read operation or a scan cycle has accessed the phy status register (register address 0x01). the miim core does not interpret the link status bit in any way. during a read operation, miilf is valid after busy is deasserted. during a scan operation, miilf is valid after nvalid is deasserted. nvalid invalid output during a scan operation, the nvalid signal indicates the validity of the miilf and prsd[15:0] signals. when nvalid is asserted, it indicates that miilf and prsd[15:0] are invalid. when nvalid is deasserted, it indicates that miilf and prsd[15:0] are valid. the meaning of nvalid is valid only during a scan opera- tion. prsd[15:0] phy read status data output the prsd[15:0] signals contain the status register data that is read from the addressed mii phy. the
2-38 signal descriptions prsd[15:0] signals are valid after the miim core deas- serts busy for a read operation and after the miim core deasserts nvalid for a scan operation. see section 3.2.3.2, read phy status register, on page 3-21 for a de?nition of the phy status register. rgad[4:0] register address [4:0] input the rgad[4:0] signals contain the address of the regis- ter within the phy the host has selected for reading or writing. the host must not change the rgad[4:0] signals while the miim core is asserting the busy signal; other- wise, the miim core may read the rgad[4:0] signals incorrectly. rstat request mii status input the host asserts the rstat signal to request that the miim function initiate a status read operation from the addressed mii phy. rstat must be at least one hclk pulse wide and must be asserted and deasserted syn- chronously with the rising edge of hclk. the host must ensure that fiad[4:0] and rgad[4:0] are valid before it asserts rstat. the host must keep the rstat signal deasserted if the scan signal is asserted. scan status read scan input when the host asserts the scan signal, the miim core causes continuous status read operations from the addressed mii phy. the host must ensure that fiad[4:0], and rgad[4:0] are valid before it asserts scan and must not change the signals during the entire scan operation. when the host deasserts scan, status read operations stop. scan must be at least one hclk pulse wide and must be asserted and deasserted synchronously with the rising edge of hclk.
miim core signals 2-39 2.3.2 miim core to phy signals the signals that connect the miim core to the phy are listed below. all signals are active high unless otherwise indicated. signal direction is with respect to the miim core. the standard ieee mii signal name references are shown in brackets. mdc miim data clock output the mdc [mdc] signal is sent by the miim block to the phy as a timing reference for transfer of information on the mdi and mdo signal lines. mdc is an aperiodic sig- nal (high-to-low and low-to-high transitions do not necessarily occur at regular intervals) that has no maxi- mum high or low times. the minimum high and low times are 200 ns each. mdi miim data in input the phy transfers status on the mdi signal to the miim core. the phy places status information on mdi synchro- nously, and the miim block samples the information synchronously. mdi is driven through an open collector or open drain cir- cuit that enables either the miim block or the phy to deassert the signal. the phy must provide a resistive pull-up of 1.5 k w 5% to maintain the signal in a high value. the miim block must incorporate a weak pull-down of2k w 5% on the mdi signal and thus may use the qui- escent state of mdi to determine if a phy is connected to the mii. if no phy is present, the mdi signal will be low. if a phy is present, the mdi signal will be high. the mdi and mdo signals are joined into one signal [mdio] outside the miim core before being connected to the phy. the mdoen signal controls the direction of data transfer on the mdio signal and whether the mdi signal or the mdo signal is active at a particular time. mdo miim data out output the miim core transfers control information on the mdo signal to the phy. the miim block places control informa- tion on mdo synchronously to hclk, and the phy sam- ples the information synchronously. mdo is driven through an open collector or open drain circuit that allows either the phy or the miim core to deassert the signal.
2-40 signal descriptions the phy must provide a resistive pull-up of 1.5 k w 5% to assert the signal. the mdi and mdo signals are joined into one signal [mdio] outside the miim core before being connected to the phy. the mdoen signal controls the direction of data transfer on the mdio signal and whether the mdi signal or the mdo signal is active at a particular time. mdoen miim data 3-state enable output the mdoen signal is a 3-state driver enable that con- trols the open-drain mdo output data signal. the miim core asserts mdoen synchronously to hclk whenever the mdo signal contains valid data. the miim core deas- serts mdoen to indicate that data is not valid. the mdi and mdo signals are joined into one signal [mdio] outside the miim core before being connected to the phy. the mdoen signal controls the direction of data transfer on the mdio signal and whether the mdi signal or the mdo signal is active at a particular time.
3-1 chapter 3 core descriptions this chapter describes the E-110 core functions and consists of the following sections: section 3.1, clock operation section 3.2, E-110 core operation standard ieee mii signal name references are shown in brackets. 3.1 clock operation this section describes all of the clocks used in the E-110 core and their operation. the clocks fall into the following categories: clocks from the phy to the mac coremtxc and mrxc clock from the host to the miim corehclk clock from the miim core to the phymdc 3.1.1 mtxc and mrxc mtxc is the transmit nibble or symbol clock input from a phy to the mac. the mtxc signal operates at a frequency of 25 mhz or 2.5 mhz. mtxc is a continuous clock that provides a timing reference for transfer of the mtxen, mtxd[3:0], and mtxer signals from the E-110 mac to the phy. the phy generates mtxc. the mtxc frequency is 25% of the transmit data rate. a phy operating at 100 mbit/s provides an mtxc frequency of 25 mhz 100 ppm. a phy operating at 10 mbit/s provides a tx_clk frequency of 2.5 mhz 100 ppm. the duty cycle of the tx_clk signal is between 35% and 60%.
3-2 core descriptions the mrxc [rx_clk] signal is a continuous clock that provides a timing reference for transfer of the mrxdv, mrxd[3:0], and mrxer signals from the phy to the E-110 mac. mrxc is an input from the phy. as long as the phy is receiving a continuous signal from the medium and can recover the mrxc clock reference and supply mrxc, the phy does not need to make a switch from the recovered clock reference to a nominal clock reference (for example, the mtxc continuous clock signal from the phy). however, if the loss of a receive signal causes the phy to lose the recovered clock reference, the phy must source mxrc from a nominal clock reference. if the phy needs to make a switch from recovered clock to nominal clock, it deasserts the mrxdv signal. during the interval between mcrs and the assertion of mrxdv at the beginning of a frame, the phy may extend a cycle of the mrxc clock by holding it in either the high or low condition until the phy has successfully locked onto the recovered clock. successive cycles of mrxc must meet the duty cycle requirement. while mrxdv is asserted, the phy recovers mrxc from the received data. mrxc has a frequency equal to 25% of the data rate of the received signal and is synchronous to recovered data. the duty cycle is between 35% and 60% and is nominally 50%. for 100-mbit/s operation, mrxc is nominally 25 mhz 100 ppm, and the minimum mrxc high and low times are 14 nsec. for 10-mbit/s operation, mrxc is nominally 2.5 mhz 100 ppm, and the minimum mrxc high and low times are 140 ns. when the mcrs signal is deasserted, the phy provides mrxc at the phys nominal clock rate (for example, the mtxc clock signal) and with nominal duty cycle. the minimum high and low times are each 35% of the nominal mrxc period except for the transition between recovered clock frequency and nominal clock frequency, which occurs while mrxdv is deasserted. following the transition from mrxdv asserted to mrxdv deasserted, the phy can keep mrxc in either the high or low condition to extend the mrxc clock by one cycle until the phy is ready to provide mrxc from a nominal clock source. the maximum high or low time for mrxc during this transition is two times the nominal clock period (a total of 80 ns for 25-mhz operation or 800 ns for 2.5-mhz operation).
E-110 core operation 3-3 3.1.2 hclk the host clock is either a 33-mhz or 25-mhz clock. the clks signal indicates the hclk frequency to the miim core. the host clock generates the miim data clock (mdc), which has minimum high and low times of 200 ns each. a 33-mhz hclk is divided by 14 to generate a 2.35 mhz mdc and a 25-mhz hclk is divided by 10 to generate a 2.5 mhz clock. to meet the minimum high and low times, the maximum frequency of mdc is 2.5 mhz. 3.1.3 mdc the mdc signal is the miim core data clock output. the mdc [mdc] signal is sent by the core to the phy as a timing reference for transfer of information on the mdi and mdo signal lines. mdc is an aperiodic signal that has no maximum high or low times. the minimum high and low times are 200 ns each. 3.2 E-110 core operation the following subsections describe the operation of the E-110 core. figure 3.1 is an overall block diagram, showing how the mac receive and transmit functions, miim core, and mac control module core interface to the host and the phy.
3-4 core descriptions figure 3.1 overall block diagram host phy tpd[7:0] hclk status/control tsv tsv[30:0] trst_l transmit function rpd[7:0] status/control rsv rsv[25:0] rrst_l receive function mtxd[3:0] mtxc status/control mrxd[3:0] mrxc status/control mac core pcs pma pmd tx rx mdi host interface mii medium mac control module tboff_sel bkoff_limit[1:0] fls_crs status/ control status/ control core ctld[15:0] fiad[4:0] rgad[4:0] prsd[15:0] status/control miim mdc mdi mdo transceiver mdio mdoen control and status registers core
E-110 core operation 3-5 3.2.1 mac core operation figure 3.2 shows the E-110 mac core transmit and receive function blocks, along with customer-de?ned transmit and receive logic blocks. figure 3.2 transmit and receive functions 3.2.1.1 mac transmit function the normal E-110 mac architecture includes an independent transmit function between the transmit logic on the host side and the mii, which is located on the phy side. the transmit logic block is customer-de?ned and buffers data from the host. the E-110 mac transmit function block performs the E-110 mac operations. figure 3.3 shows how the transmit function interfaces to the rest of the system. figure 3.3 transmit function interface byte stream transmit receive transmit nibbles to mii receive nibbles from mii transmit from host receive to host E-110 mac core transmit logic receive logic byte stream function function transmit logic transmit function external mii phy transmit mac E-110 byte stream control status transmit statistics host statistics logic mii
3-6 core descriptions the general ?ow of transmit packet data is from the host through the transmit control logic to the transmit function block and then into the media phy device. the transmit function block of the E-110 mac generates 100base-t tr ansmit mii nibble data streams in response to byte streams supplied from the transmit logic. the transmit function performs the required deferral and backoff algorithms and reports per packet statistics. the transmit function operates on the 25- or 2.5-mhz mii transmit nibble clock. the E-110 mac core monitors the physical medium even when it has nothing to transmit by tracking the carrier sense (crs) signal from the phy. when the medium is busy, the mac defers to the frame in progress by delaying any pending transmission of its own. when the phy deasserts crs, it indicates to the mac that the last bit of the frame has been transmitted onto the physical medium. the mac then continues to defer transmission for a period called the interpacket gap (ipg). the purpose of deference is to ensure a minimum interframe spacing to allow a station recovery time to process a received frame and for the medium to recover. deference applies to both 10-mbit/s and 100-mbit/s operation. there is an ipg counter inside the mac that begins counting after a deferral. you can specify three threshold values for the counter: ipgr1[6:0]non back-to-back ipg, part 1 ipgr2[6:0]non back-to-back ipg, part 2 ipgt[6:0]back-to-back transmit ipg to provide maximum ?exibility for the ipg in both full-duplex and half- duplex operation, these thresholds are programmable. due to possible variations in phy propagation delays, the programmable thresholds may need to be adjusted to meet ieee 802.3u deference requirements. as soon as the crs signal is deasserted, the mac begins timing the ipg with the ipg counter. ipg half-duplex operation C the ipgt[6:0] 1 signals contain the threshold value to be compared to the ipg counter. the threshold value is used for back-to-back mac transmissions. as soon as the macs ipg count is equal to ipgt[6:0], the mac may begin transmission.
E-110 core operation 3-7 ipgr1[6:0] is the threshold value used to reset the macs ipg counter if crs is detected within a short time after receiving a packet (see figure 3.5). if crs is asserted before the ipg counter value reaches the ipgr1[6:0] threshold, the mac resets the ipg counter because the crs may have occurred due to a collision fragment (see figure 3.5). if the ipg counter makes it past the ipgr1[6:0] 1 threshold, the mac does not reset the ipg counter so that the E-110 mac is able to access to the medium without being constantly deferred by other stations trying to gain access. ipgr2[6:0] 2 is the threshold value for measuring the ipg if the mac has been receiving and the host wants the mac to transmit. that is, when the ipg counter has exceeded the value in ipgr1[6:0] and reaches the value in ipgr2[6:0], the mac can transmit. because ipgr1[6:0] and ipgr2[6:0] are programmable, ipgr1[6:0] may be set to a threshold that is a fraction of ipgr2[6:0] to conform to the ipg rules of the ieee 802.3/802.3u speci?cations. 3 figure 3.4 and figure 3.5 illustrate half-duplex ipg operation. figure 3.4 half-duplex back-to-back ipg operation 1. a value of 18 (decimal) for ipgt[6:0] results in an ipg of 960 ns for 100-mbit/s operation (the value given in ieee 802.3u, section 1.4.102) at the mii. when ipgt[6:0] is set to 18, the ipg counter counts from 0 to 18 (19 clocks total) using the nibble clock. the nibble clock runs at 25 mhz (40 ns) for 100-mbit/s operation and 2.5 mhz (400 ns) for 10-mbit/s opera- tion). the 19 clocks plus a 5-clock internal core delay results in 24 clocks, which yields 960 ns for 100-mbit/s operation or 9.6 m s for 10-mbit/s operation. depending on phy propagation delays, the value for ipgt[6:0] may need to be adjusted to meet the ipg requirement at the network interface. 1. the nominal value for ipgr1[6:0] is 11 (decimal). 2. a nominal value for ipgr2[6:0] is 18 (decimal). the phy may have its own propagation de- lay and the value of 18 (decimal) may or may not be the correct value for a particular phy. 3. see ieee 802.3 sections 4.2.3.2.1 and 4.2.3.2.2. see also ieee 802.3u section1.4.102. crs ipg counter 0 18 (ipgt[6:0]) transmit frame ipg ipg
3-8 core descriptions figure 3.5 half-duplex non back-to-back ipg operation ipg full-duplex operation C in full-duplex mode, the mac never sees the crs signal asserted because crs is disabled when the fulld signal is asserted. for this reason, in full-duplex mode the mac does not defer on crs. in full-duplex mode, the mac can begin to create the ipg as soon as transmission is done, regardless of the state of crs. when the mac has been receiving and the host wants the mac to transmit a packet, the mac looks at the ipgr2[6:0] threshold. the mac compares the ipg counter to the ipgr2[6:0] threshold in situations where a reception is followed by a transmission. when the host wants to perform back-to-back transmit operations through the mac, the mac compares the ipg counter to the ipgt[6:0] threshold. for full-duplex operation, the ipgr2[6:0] threshold should normally be set equal to ipgt[6:0]. 1 figure 3.6 and figure 3.7 illustrate full-duplex ipg operation. figure 3.6 full-duplex back-to-back ipg operation crs ipg counter 0 18 (ipgr2[6:0]) receive frame transmit frame 11 (ipgr1[6:0]) ipg collision fragment 1. a value of 18 (decimal) for ipgr2[6:0] and ipgt[6:0] results in an ipg of 960 ns at the mii for 100-mbit/s operation and 960 m s for 10-mbit/s operation. crs ipg counter 0 18 (ipgt[6:0]) transmit frame ipg ipg
E-110 core operation 3-9 figure 3.7 full-duplex non back-to-back ipg operation when instructed, the transmit function adds a preamble and sfd to the supplied packet data and, if requested, appends a generated fcs. the E-110 mac transmit function adds bytes of zero before the appended fcs to pad packets with fewer than 60 data bytes. the transmit function detects and enforces collisions with jams and manages transmission retries. the transmit function block operates on the 25-mhz (100-mbit/s operation) or 2.5-mhz (10-mbit/s operation) transmit nibble or symbol clock (mtxc) supplied by the phy. the phy clock must be a continuous clock. the connecting interface to the transmit control logic also operates on the same transmit nibble clock and communicates synchronously with the transmit function. the transmit data is supplied to the transmit function a byte at a time from the transmit control logic on the tpd[7:0] signals and output to the mii a nibble at a time as de?ned in the mii speci?cation. transmit data bytes are transferred from the host at one-half the nibble clock rate. the transmit data is also sent to the transmit function block fcs generator/checker. the mii output nibbles (mtxd[3:0]) are only valid when the mtxen signal is asserted. the transmit function supplies nibbles of zero when mtxen is not asserted. when mtxen is asserted, the transmit function supplies preamble, sfd, transmit data, fcs, jam, or pad nibbles. the operation of the E-110 mac transmit function is affected by the following control signals: no preamble (nopre), pad enable (paden), full-duplex (fulld), fcs enable (crcen), and huge packet enable (hugen). the host must appropriately manage any transitions of these signals and ensure that only valid combinations of controls signals are used, as described below. crs ipg counter 0 18 (ipgr2[6:0]) receive frame transmit frame ipg
3-10 core descriptions nopre. if no preamble is selected (the nopre signal is asserted), the preamble and start of frame nibbles come directly from the host and are not examined by the E-110 mac transmit function. if nopre is not asserted, the mac encodes the preamble including the sfd and outputs it at the beginning of the packet. paden. when asserted, the paden signal instructs the transmit function to pad packets of fewer than 60 bytes with bytes of zero. the crcen signal must also be asserted because the mac must calculate the fcs when it inserts its own pad bytes. if paden is not asserted, the host must ensure that packets contain at least 60 bytes; otherwise, the packet is invalid (too short). fulld. when asserted, the fulld signal instructs the transmit function to operate in full-duplex mode by not deferring to the crs signal and not responding to the col signal. crcen. if the crcen signal is deasserted, the last four data bytes of a packet must be a valid fcs provided by the host and are checked by the macs transmit function. if the fcs is not valid, the mac asserts the fcs error signal (tsv21) in the transmit statistics vector. if crcen is asserted, the transmit function generates an fcs from the transmit data bytes and pad bytes of the packet and outputs it at the end of the packet. you can change crcen on a packet-by-packet basis, but you must not change it during an active transmission. hugen. when asserted, the hugen signal instructs the mac transmit function to allow transmission of packets up to 32 kbytes rather than the normal limit of 1518. however, the mac core does not enforce the length of the maximum packet. instead, the higher layer protocols must assure that the packet size does not exceed ieee speci?cations. for more information about these signals, refer to chapter 2. a packet transmission from the host to the transmit function begins when the host asserts the tpsf signal. when the tpsf signal is asserted, the host may also present the ?rst data byte of the packet on tpd[7:0]. the host may also delay supplying the ?rst data byte on tpd[7:0] until the transmit function has sent out the preamble. assuming the nopre signal is not asserted, the transmit function (after any pending backoff and needed deference) begins to generate
E-110 core operation 3-11 preamble and start of frame nibbles. after generating the sfd, the transmit function uses the contents of tpd[7:0] as the ?rst data byte and asserts the tpud signal to the host. if the host had not already supplied the ?rst data byte, it must recognize an underrun condition and assert tpur, which causes the transmit function to abort the packet. the host thus has at least eight byte times (the length of the preamble plus sfd) to supply the ?rst data byte after asserting tpsf. conversely, the tpud signal might not be asserted for over 500,000 bit times in the case of a maximum backoff and deferral. after once seeing tpud asserted, the host must then deassert tpsf and supply new transmit packet data bytes every other mtxc clock cycle. the host continues supplying new data bytes up until the last data byte of the packet, when it asserts the tpef signal. if the host is unable to correctly supply new transmit packet data bytes, the transmit function must assert tpur. when the host asserts the tpur signal, the mac asserts the mtxer signal with the last nibble it transmits to indicate that this nibble may not have valid information. each data byte must be stable on the tpd[7:0] signals for two transmit clock periods. the tpef signal must also be valid for two transmit clock periods. the tpsf signal and the ?rst data byte must be kept asserted for one transmit clock period after the tpud signal is asserted. alternatively, if nopre is asserted, the host must supply a data byte as soon as it asserts tpsf. the transmit function does not supply a preamble when nopre is asserted, so the preamble must come from the host. the host must supply the ?rst valid data byte on the tpd[7:0] signals as soon as it asserts tpsf. the packet is terminated when the host asserts the tpef signal at the end of the frame, which causes the transmit function to pad the packet with bytes of zero if necessary (provided the paden signal is asserted) and append the fcs (provided the cren signal is asserted), then terminate transmission. the transmit function asserts the tpdn signal when the transmission is successfully completed. packets longer than 1518 bytes (hugen signal deasserted) or 32 kbytes (hugen signal asserted) are truncated. any collision causes the transmission to be truncated and extended with jam bytes of zeroes to ensure that the entire network sees the collision. collision detections other than a 16th collision without an intervening non-colliding transmission cause the tprt signal to be asserted, which
3-12 core descriptions informs the host to restart the packet. late collisions are treated just the same as any other collisions if the rtryl control input is asserted; otherwise, a late collision causes an abort. tpab is asserted when any of the following conditions exists: a 16th collision occurs without an intervening non-colliding transmission. a packet transmission attempt is made that has excessive deferrals (greater than 6,072 transmit nibble clocks when the hugen signal is deasserted or greater than 131,072 transmit nibble clocks when hugen is asserted). a transmission occurs with under?ow . (the host did not supply new transmit packet bytes fast enough to keep up with the mac transmit function.) when the tpab signal is asserted, the host must discard the packet and try again with the next packet available. a subsequent packet transmission, indicated by the assertion of the tpsf signal, deasserts the tpdn), tprt, and tpab signals. transmit function to host interface C the interface between the E-110 mac transmit function and the host consists of the following: transmit control logic transmit byte stream signals control signals between the mac and host the transmit control logic serves two basic purposes. it contains temporary storage for transmit bytes from the host in the form of buffers or fifos, and it translates host signals to transmit byte stream signals that are compatible with the mac transmit function signals. for details on the mac transmit function interface, see section 2.1.1, transmit function to host signals, on page 2-3. the transmit byte stream from the host to the transmit function consists of an eight-bit parallel data interface consisting of the tpd[7:0] signals. the control signals from the host to the macs transmit function are tpsf, tpef, and tpur.
E-110 core operation 3-13 the control signals from the macs transmit function to the host are tpud, tpdn, tprt, tpab, and trst_l. transmit function to statistics interface C the interface between the transmit function and external statistics collection logic consists of the tsv[30:0] and tsvp_l signals. for more details on these signals, see section 2.1.6, statistics vector to host signals, on page 2-21. transmit function to mii interface C the mii interface of the transmit function allows the E-110 mac to be compatible with mii-supported phys. the mii interface signals conform to the ieee 802.3u standard for 100-mbit/s baseband networks. the mii interface consists of a set of transmit signals and a set of receive signals. the transmit signals are mtxd[3:0], mtxen, mtxer, mcrs, mcol, and mtxc. for more details on these signals, see section 2.1.4, mii to phy signals, on page 2-10. 3.2.1.2 mac receive function the normal E-110 mac architecture includes an independent receive channel between the host and the mii, which is located on the phy side. the receive function block provides the ethernet mac operations described in this section. figure 3.8 shows how the receive function interfaces to the rest of the system.
3-14 core descriptions figure 3.8 receive function interface the general ?ow of receive packet data is a from a phy into the receive function block and out through the receive logic to the host system. the receive function block of the E-110 mac interprets 100base-t mii receive data nibble streams and supplies correctly formed packet byte streams to the host. 1 the receive function searches for the sfd at the beginning of the packet, veri?es the fcs, and detects any dribble nibbles or receive code violations. after any packet has been sent to the host from the receive function, the mac produces a receive statistics vector. a long event or a carrier event is noted for a subsequent statistics vector. see the de?nition of the rsv[25:0] signals in chapter 2 for an explanation of long and carrier events. the receive function detects and removes the preamble and sfd bytes at the beginning of the received packet. the E-110 mac receive function enforces a minimum ipg between the end of the data portion of one packet, which contains the fcs, and the beginning of the data (destination address) portion of the following packet. the ipg allows for the stations and media to recover between transmissions. 1. see section 1.2.1, fast ethernet overview, on page 1-2 for an explanation of 100base-t. receive logic receive function external receive mac function E-110 byte stream control status receive statistics host statistics logic mii asic mii phy
E-110 core operation 3-15 the receive function block operates on the 25-mhz (100-mbit/s operation) or 2.5-mhz (10-mbit/s operation) transmit nibble or symbol clock (mrxc) supplied by the phy. mrxc is considered to be a continuous clock although it may have gaps as de?ned in the ieee 802.3u mii speci?cation. the connecting interface to the host also operates on the same receive nibble clock and communicates synchronously with the receive function. refer to section 2.1.2, receive function to host signals, on page 2-5 for detailed requirements on how the host interfaces to the receive function. the receive function supplies the receive data a byte at a time to the host on the rpd[7:0] signals and inputs the receive data from the phy a nibble at a time. receive data bytes are transferred at one-half the nibble clock rate. the receive nibble data is also sent to the receive function fcs checker. mii input nibbles (mrxd[3:0]) are only valid when mrxdv is asserted. the fulld and hugen control signals affect the operation of the E-110 mac receive block. the host must appropriately manage any transitions of these signals and ensure that only valid combinations of controls signals are used. the E-110 mac receive function also responds to the mtxen signal from the transmit function when not in full-duplex mode. if mtxen is asserted, it indicates that a data packet is being transmitted. if the mac is in half-duplex mode, the receive function is disabled when mtxen is asserted and enabled when it is deasserted. in full-duplex mode, the mtxen signal does not affect the receive function. a packet transfer to the host from the receive function begins when the receive function asserts the rpsf and rpdv signals along with the ?rst byte of received packet data after removing the preamble and sfd. for subsequent data bytes, the receive function asserts only the rpdv signal until the last byte, when it asserts both rpdv and rpef. there is no provision for ?ow control feedback from the host to the receive function, so the host must handle the receive packet data bytes as they arrive. the receive packet starts at the mii interface when the phy asserts the mrxdv signal and ends when the phy deasserts the mrxdv signal. the receive function passes packets less than or equal to 1518 bytes (or less than or equal to 32 kbytes with the hugen signal asserted). longer packets are truncated. collision fragments and other carrier events (for example, a preamble but no sfd) are received as packets if a valid
3-16 core descriptions preamble is seen following a valid ipg. the mac asserts the rsv25 signal, one of the bits of the receive statistics vector, to indicate that a carrier event occurred. the receive function notes a long event if the mcrs signal is asserted for over 24,288 bit times if the hugen signal is not asserted and over 524,288 bit times if hugen is asserted. other modules can use the rrst_l signal as a host reset synchronized to the mrxc receive clock. because the mrxc signal can be slow with respect to a host reset pulse, or even stopped, 1 the mac latches the host reset signal, hrst_l, without using mrxc and uses the hrst_l signal to assert rrst_l asynchronously to mrxc. the mac then deasserts rrst_l synchronously on the transition of the mrxc clock. receive function to host interface C the interface between the E-110 mac receive function and the host consists of the following: receive control logic receive byte stream signals status signals the receive control logic is a designer-speci?c implementation. it may contain temporary storage in the form of buffers or fifos for receive bytes from the mac, and it may translate receive byte stream signals from the receive function that are compatible with the host interface signals. the host receives the byte stream from the receive function over an eight-bit parallel data interface consisting of the rpd[7:0] signals. the status signals from the receive function to the host are rpdv, rpsf, rpef, rrst_l, crco[9:1], crcg, bco, mco, and byte7. for more details on these signals, see the subsection entitled receive function to host signals on page 2-5. receive function to statistics interface C the interface between the receive function and external statistics collection logic consists of the rsv[25:0] and rsvp_l signals. for more details on these signals, see section 2.1.6, statistics vector to host signals, on page 2-21. 1. mrxc from the phy may be extended by a cycle when the phy switches from recovered clock to nominal clock. see the subsection entitled mrxc receive nibble or symbol clock input on page 2-11.
E-110 core operation 3-17 receive function to mii interface C the mii of the receive function allows the E-110 mac to be compatible with mii phys. the mii interface signals conform to the ieee 802.3u standard for 100 mbit/s baseband networks. the mii consists of a set of transmit signals and a set of receive signals. the receive signals are mrxd[3:0], mrxdv, mrxer, and mrxc. for more details on these signals, see section 2.1.4, mii to phy signals, on page 2-10. 3.2.2 mac control module core operation the optional mac control module core implements full-duplex ?ow control for the E-110 core. control frames currently have one de?ned opcode: pause. the pause operation is used to inhibit transmission of data frames for a speci?ed period of time. using the mac control module core, a client wishing to inhibit transmission of data frames from another station generates a pause control frame. the pause control frame contains a reserved multicast address of 01-80-c2-00-00-01, a pause opcode, and a pause time ?eld, consisting of a 16-bit value expressed in slot times. the pause operation does not inhibit the transmission of mac control frames but it does inhibit transmission of mac data frames until the pause timer expires. pause frames, however, do not affect the E-110 core data transmission until frames currently being transmitted are ?nished. upon receipt of a valid mac control frame with the pause opcode and a destination address equal to a multicast address of 01-80-c2-00-00-01 or its own unicast address, the mac control module loads its pause timer with the value sent in pause time ?eld. if the pause time ?eld is non- zero, the E-110 core is said to be paused from transmitting data frames and waits for pause time number of slot times to initiate transmission. new pause frames override previous pause frames. the mac control module core does not update its pause timer value when it receives an invalid control frame (one containing a bad fcs, code errors, or dribble nibbles or a control packet less than minimum packet size). the mac control module reports statistics for management purposes. along with the rsv[25:0] and tsv[30:0] statistics vector signals, the xmt_pausef, rsvd_pausef and unsupp_opcode signals are available to the host to read for management purposes.
3-18 core descriptions a mirror counter in the mac control module core is loaded with a value when a pause control packet is sent. the purpose of the mirror counter is to roughly keep track of the other stations pause timer. the mirror value has to take into account the packet transmit time and the pause value load time on the other end. the packet transmit time is the time it takes for the stations own control packet to be transmitted. the pause value load time is the time it takes for the other station to decode the packet, check the fcs, and load the pause time into its pause timer. the station receiving the control packet loads x (pause time) into the pause timer and the station transmitting the control packet loads x+ n (n is a programmable value) into the mirror counter. the mirror counter allows the transmitting station to send another pause control packet before the receiving stations pause timer expires if the receive buffer congestion has not been alleviated. 3.2.3 miim core operation the optional miim core is a 16-bit parallel interface on the host side and a 4-signal interface (mdo, mdi, mdoen, and mdc) on the mii side. the miim controls a phy and gathers status from it. the register layout for a phy is shown in table 3.1. all phys that incorporate an mii contain the basic register set (registers 0 and 1). registers 2 through 7 are part of the extended register set. table 3.1 miim register set register address register name basic/extended 0 control basic 1 status basic 2C3 phy identi?er extended 4 auto-negotiation advertisement extended 5 auto-negotiation link partner ability extended 6 auto-negotiation expansion extended 7 auto-negotiation next page transmit extended 8C15 reserved extended 16C31 vendor-speci?c extended
E-110 core operation 3-19 3.2.3.1 write phy control register to write the control register in the phy, the host places the phy address on the miim cores fiad[4:0] signals and the address of the control register within the phy on the cores rgad[4:0] signals. the host keeps the rstat signal deasserted during a write operation. the host ctld[15:0] signals contain the data that is sent to the phy control register. when the host asserts the lctld signal, the data on the fiad[4:0], rgad[4:0], and ctld[15:0] buses are loaded into the miim core, and the core asserts the busy signal. the host must not change any of the address or data lines while busy is asserted. during the time the miim core asserts busy, it uses the mdo, mdc, and mdoen signals to transport data to the control register of the selected phy, using the management frame format speci?ed in the mii speci?cation. the mdo and mdi signals are normally connected to a 3-state bidirectional transceiver on the phy side of the miim core. a single bidirectional data line from the transceiver, mdio, transfers control and status data to and from the phy. the mdoen signal controls the transceiver direction.
3-20 core descriptions the phy control register (register 0) layout is shown in table 3.2. table 3.2 phy control register bit de?nitions bit name description operation 15 reset 1 = phy reset 0 = normal operation r/w, 1 sc 2 1. r/w = read/write. 2. sc = self-clearing. (after the bit is set to one, the operation takes place and the phy clears the bit back to zero.) 14 loopback 1 = enable loopback 3 0 = disable loopback 3. loopback connects the phy transmit signals to the phy receive signals, which allows network isolation and troubleshooting. r/w 13 speed selection 1 = 100 mbit/s 0 = 10 mbit/s r/w 12 auto-negotiation enable 1 = enable auto-negotiation 4 0 = disable auto-negotiation 4. auto-negotiation is a signalling method described in clause 28 of the ieee 802.3u speci?cation. it allows each node to de?ne its own operating mode (for example, 10 mbit/s, 100 mbit/s, 100base-tx, 100base-t4, or full- duplex) and to determine the operating mode of the node to which it is con- necting. auto-negotiation is conceptually similar to the signalling method used with modems, where two nodes negotiate their capabilities and settle on the highest common denominator. r/w 11 power down 1 = power down 0 = normal operation r/w 10 isolate 1 = electrically isolate phy from mii 0 = normal operation r/w 9 restart auto- negotiation 1 = restart auto-negotiation process 0 = normal operation r/w, sc 8 duplex mode 1 = full-duplex 0 = half-duplex r/w 7 collision test 1 = enable col signal test 0 = disable col signal test r/w 6C0 reserved write as 0, ignore on read r/w
E-110 core operation 3-21 3.2.3.2 read phy status register to read the status register in the phy, the host places the phy address on the miim cores fiad[4:0] signals and the address of the desired phy register on the rgad[4:0] signals. the host asserts rstat to indicate a read operation. when the host asserts the rstat signal, the miim core loads the fiad[4:0] and rgad[4:0] address information into the core and the core asserts the busy signal. the host must not change any of the address lines while busy is asserted. while the miim core asserts busy, it uses the mdo, mdc, and mdoen signals to read the phy status register. the phy responds to the read request and sends data to the miim core by means of the mdi signal. after the miim core has received all of the data from the phy status register, it deasserts the busy signal and places the data on the prsd[15:0] signals to the host. data is transferred to and from the phy using the management frame format speci?ed in the mii speci?cation. the phy status register (register 1) layout is shown in table 3.3. table 3.3 phy status register bit de?nitions bit name description operation 15 100base-t4 1 1 = phy able to perform 100base-t4 0 = phy not able to perform 100base-t4 r/o 2 14 100base-tx 3 full-duplex 1 = phy able to perform full-duplex 100base-tx 0 = phy not able to perform full-duplex 100base-tx r/o 13 100base-tx half-duplex 1 = phy able to perform half-duplex 100base-tx 0 = phy not able to perform half-duplex 100base-tx r/o 12 10 mbit/s full-duplex 1 = phy able to operate at 10 mbit/s in full-duplex mode 0 = phy not able to operate at 10 mbit/s in full-duplex mode r/o 11 10 mbit/s half-duplex 1 = phy able to operate at 10 mbit/s in half-duplex mode 0 = phy not able to operate at 10 mbit/s in half-duplex mode r/o 10C6 reserved ignore when read r/o (sheet 1 of 2)
3-22 core descriptions 5 auto-negotiation complete 1 = auto-negotiation process completed 0 = auto-negotiation process not completed r/o 4 remote fault 1 = remote fault condition detected 0 = no remote fault condition detected r/o, lh 4 3 auto-negotiation ability 1 = phy is able to perform auto-negotiation 0 = phy is not able to perform auto-negotiation r/o 2 link status 1 = link is up 0 = link is down r/o, ll 5 1 jabber detect 1 = jabber condition detected. jabber is de?ned as a condi- tion on an ethernet network when a node transmits for longer than the speci?ed time. 0 = no jabber condition detected r/o, lh 0 extended capability 1 = extended register capabilities 0 = basic register capabilities r/o 1. 100base-t4 allows users to run 100base-t over four pairs of category 3, 4, or 5 utp cabling. 2. r/o = read-only. 3. 100base-tx allows users to run 100base-t over two pairs of category 5 utp and type 1 stp. 4. lh = latching high. when a fault condition occurs (remote fault or jabber), the bit is set. the bit remains set until the phy status register is read via the miim or the phy is reset, at which time the bit is cleared. 5. ll = latching low. when the link is not valid, the phy clears the bit. it remains cleared until the phy status register is read via the miim. the bit is set when the phy has determined that a valid link has been established. table 3.3 phy status register bit de?nitions (cont.) bit name description operation (sheet 2 of 2)
E-110 core operation 3-23 3.2.3.3 scan operation when the host asserts the scan signal, the miim core performs a continuous read operation of the phy register speci?ed by the fiad[4:0] and rgad[4:0] signals. the scan operation can be used to poll the phy status register (address 0x001), which allows the host to monitor the link status bit. the miilf signal output re?ects the state of the link status bit in the phy status register. during a scan operation, the miim core keeps the busy signal asserted until the last read is ?nished. if the scan signal is deasserted before the end of the current read operation, the miim core completes the current read operation and then deasserts the busy signal. for every read performed during the scan operation, the prsd[15:0] signals are also updated. during the scan operation, the nvalid signal should be used to qualify the validity of the prsd[15:0] and miilf signals. when the scan signal is asserted to perform a continuous scan, the rstat signal must be deasserted.
3-24 core descriptions
4-1 chapter 4 functional timing this chapter examines various E-110 functional timing scenarios. the key timing relationships are discussed. for details of the operation of each of the signals discussed, refer to chapter 2, signal descriptions. this chapter contains the following sections: section 4.1, mac functional timing section 4.2, miim core functional timing section 4.3, transmit collision functional timing 4.1 mac functional timing the following subsections describe the functional timing for mac operations, including mac receive and transmit packet timing. 4.1.1 mac receive packet timing the timing for a typical receive packet is shown in figure 4.1. notice that the phy asserts the mcrs and mrxdv signals at the beginning of packet reception. the phy asserts mcrs asynchronously as soon as it detects a non-idle medium. the phy also asserts mrxdv synchronously to the rising edge of mrxc when it has decoded a valid preamble.
4-2 functional timing figure 4.1 E-110 mac receive packet timing mrxc 0 5 d 4 0 1 0 2 0 a 4 0 3 0 4 mcrs mrxdv mrxd[3:0] mrxer crcg valid fcs crco[9:1] byte7 mco bco rpsf 43 04 00 01 20 03 40 1 3 13 a4 00 rpdv rpd[7:0] rpef rrst_l rsvp_l rsv[25:0] valid mco valid bco valid 3 note: rsvp_l is asserted one clock before rpef.
mac functional timing 4-3 4.1.1.1 preamble every packet is preceded by a preamble consisting of seven octets followed by a single sfd octet. the preamble and sfd are shown in figure 4.2. figure 4.2 packet preamble and sfd in figure 4.2, the preamble and sfd are shown in the serial bit order of reception. for each octet, the leftmost bit in each octet value represents the least signi?cant bit of the octet and the rightmost bit represents the most signi?cant bit of the octet. the preamble consists, then, of seven octets of 0x55. the sfd octet (0xd5) indicates the start of frame and follows the preamble. in figure 4.1, the mrxd[3:0] data changes in the beginning from 0x0 to 0x5 to 0xd, which represents the transition from idle to preamble to sfd. 4.1.1.2 nibble and byte assembly data is passed to the E-110 mac from the phy as nibbles on the mrxd[3:0] lines. because the data is received least signi?cant bit ?rst, the low nibble is received, then the high nibble. figure 4.1 shows that the phy transfers the mrxd[3:0] nibbles received after the sfd to the E-110 mac in the following order: 0x3, 0x4, 0x4, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x2, 0x0, 0x0, 0x3, 0x0, 0x0, 0x4, and so on. the mac then assembles the nibbles into bytes with the nibbles in reverse position, so that the high and low nibbles are in the proper order for the host on the rpd[7:0] signals. the rpd[7:0] data in figure 4.1 shows that the mac sends the bytes to the host in the following order: 0x43, 0x04, 0x00, 0x01, 0x20, 0x03, 0x40, and so on. a packet transmission to the receive control logic from the receive function begins when the receive function asserts the rpsf and rpdv signals along with the ?rst byte of received packet data after removing the preamble and sfd. for subsequent data bytes, the receive function asserts only the rpdv signal until the last byte, when it asserts both the rpdv and rpef signals. 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011 sfd preamble lsb lsb lsb lsb lsb lsb lsb lsb msb msb msb msb msb msb msb msb
4-4 functional timing 4.1.1.3 fcs operation the crco[9:1] lines re?ect the state of the receive function fcs register after the ?rst 48 bits (six bytes) of the receive packet. the crcg signal, when asserted, indicates that the crco[9:1] signals are valid. the crco[9:1] signals contain the nine-bit hash function computed from the destination address. the nine-bit hash function is generated after the ?nal destination address bit is received. the nine-bit value can be used as an index into an external multicast ?lter hash table to determine if the frame should be received. external logic can decide to either accept or reject the incoming frame. 4.1.1.4 end of frame when asserted, the rpef signal marks the last byte of the receive packet. at the end of the packet, the E-110 mac asserts rsvp_l, an active-low pulse that indicates the availability of a new receive statistics vector on the rsv[25:0] lines. 4.1.2 mac transmit packet timing the timing for a typical transmit packet is shown in figure 4.3.
mac functional timing 4-5 figure 4.3 E-110 mac transmit packet timing 4.1.2.1 start of transmission when the mac is ready to begin a packet transmission, it asserts the mtxen signal to the phy to indicate that the mac is presenting nibbles on the mii for transmission. 4.1.2.2 preamble in the example shown in figure 4.3, the mac begins sending the preamble to the phy. the preamble consists of the value 0x5 on the mtxc 0 5 d f 0 0 mtxen mtxd[3:0] tpud tpsf tpef 6 4 tpd[7:0] 9 a 8 3 4 0 1 1 0 fcs a9 38 04 00 10 00 01 64 ff cb tsvp_l tsv[30:0] tpdn mtxer tpab tprt tpur trst_l valid 1 1. transmit status vector valid.
4-6 functional timing mtxd[3:0] lines (as soon as mtxen is asserted). as an option, the host may assert the nopre signal to instruct the mac not to send a preamble, in which case the host itself must supply the preamble. after sending 15 nibbles of 0x5, the mac sends a 0xd, which is the sfd. the preamble and sfd add up to 16 nibbles (8 bytes). 4.1.2.3 nibble and byte assembly data is passed from the E-110 mac to the phy as nibbles on the mtxd[3:0] lines. the tpd[7:0] data in figure 4.3 shows that the mac receives the bytes from the host in the following order: 0xa9, 0x38, 0x04, 0x00, 0x10, 0x00, 0x01, and so on. because the data is sent to the phy least signi?cant bit ?rst, the low nibble is sent ?rst, followed by the high nibble. the mac must assemble the host bytes into nibbles with the nibbles in reverse position, so that the low and high nibbles are in the proper serial bit order for transmission to the phy on txd[3:0]. figure 4.3 shows that the mac transfers the mtxd[3:0] nibbles to the phy after the sfd in the following order: 0x9, 0xa, 0x8, 0x3, 0x4, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x1, 0x0, and so on. mtxd[3:0] nibbles are valid only when the mtxen signal is asserted. the transmit function supplies nibbles of zero when mtxen is not asserted. when mtxen is asserted, the transmit function supplies preamble, sfd, transmit data, fcs, jam, or pad nibbles. 4.1.2.4 end of frame when asserted, the tpef signal marks the last byte of the transmit packet and must be valid for two transmit clock periods. the mac appends the fcs bytes to the packet data from the host and then asserts the tpdn signal to the host, indicating successful packet completion. the mac then asserts the tsvp_l signal to indicate the availability of a new transmit statistics vector (tsv[30:0]). 4.2 miim core functional timing the following subsections describe the functional timing for miim operations, including miim write and read timing.
miim core functional timing 4-7 4.2.1 miim write operation the timing for an miim write operation from the miim core to a phy is shown in figure 4.4. figure 4.4 miim write operation the timing shows the sequence of events to write to a phy control register. the values used for addresses and data are illustrative only. the host asserts the lctld signal to initiate the write operation. lctld indicates that the host data lines (ctld[15:0]), phy address (fiad[4:0]), and phy register address (rgad[4:0]) are valid. in the example, ctld[15:0] contains 0x55aa, which is the data being written to the phy control register. fiad[4:0] contains 0x0a, and rgad[4:0] contains 0x15. as soon as the host loads the data with the lctld signal, the miim core asserts the busy signal to the host, indicating that a phy write operation is in process. the core asserts the mdoen signal to enable the output data line, mdo, to the phy. the core then clocks out data to the phy on each rising edge of mdc in accordance with the miim frame format described in the ieee 803.2u speci?cation. the frame structure is brie?y summarized below and is illustrated in figure 4.4. lctld hclk busy ctld[15:0] 0x55aa fiad[4:0] 0x0a mdoen mdc invalid prsd[15:0] 0x15 rgad[4:0] mdo phy addr (0x0a) reg addr (0x15) 0xaa 0x55 st wr ta
4-8 functional timing on mdo, the miim core sends a preamble of 32 contiguous logic one bits, followed by a start of frame pattern (st), which is a zero-one combination. the next two bits, a zero-one sequence (wr) speci?es that the core is performing a write operation. the phy address, 0x0a, is next, followed by the phy register number, 0x15. the next ?eld is the two-bit turnaround (ta) ?eld. for a write operation, the ?eld is de?ned to be a one-zero sequence. finally, the core sends the data, 0x55aa. 4.2.2 mac miim read operation the timing for an miim read operation from a phy to the miim core is shown in figure 4.5. figure 4.5 miim read operation the timing shows the sequence of events to read from a phy status register. the values used for data and address are illustrative only, and lctld hclk busy ctld[15:0] fiad[4:0] 0x0a mdoen mdc prsd[15:0] 0x15 rgad[4:0] mdo phy addr (0x15) reg addr (ox0a) 0xaa 0x55 st ta r s tat rd mdi 0xaa55
transmit collision functional timing 4-9 the values used in this read example bear no relation to those used in the write example. the host asserts the rstat signal to initiate the read operation. rstat indicates that the host phy address (fiad[4:0]) lines and phy register address lines (rgad[4:0]) are valid. in the example, fiad[4:0] contains 0x15, and rgad[4:0] contains 0x0a. as soon as the host asserts rs tat, t h e miim core asserts the busy signal to the host, indicating that a phy read status operation is in process. the core asserts the mdoen signal to enable the output data line, mdo, to the phy. the core then clocks out data to the phy on mdo and clocks in status from the phy on mdi on each rising edge of mdc in accordance with the miim frame format described in the ieee 803.2u speci?cation. on mdo, the core sends a preamble of 32 contiguous logic one bits, followed by a start of frame pattern (st), which is a zero-one combination. the next two bits, a one-zero sequence (rd), specify that the miim core is performing a read operation. the phy address, 0x15, is next, followed by the phy register number, (0x0a). the next ?eld is the two-bit turnaround (ta) ?eld. for a read operation, the ?eld is de?ned to be a one-bit period in which the phy remains in a high-impedance state followed by a one-bit period during which the phy drives a zero on the mdo line. finally, the core deasserts the mdoen signal, which enables the mdi input and the phy sends the status, 0xaa55, to the core on mdi. the core deasserts the busy signal at the end of the sequence, at which time it drives valid data on the prsd[15:0] lines to the host. 4.3 transmit collision functional timing figure 4.6 is a functional timing diagram for transmit collisions. for a description of the transmit collision operation, see section 3.2.1.1, mac transmit function, on page 3-5.
4-10 functional timing figure 4.6 transmit collision functional timing mtxc a6 48 a6 tpsf tpd[7:0] c4 0 5 0 5 0 xxxxxx valid 5 0 0 tpud tpef mtxen mtxd[3:0] mcol tpdn tsv[30:0] tsvp_l mcrs xxxxxx 00 mrxc mrxer, rpdv, mrxdv mrxd[4:0] rpd[7:0] rsv[25:0] rsvp_l tpab, tpur, mtxer rpsf, rpef tprt
5-1 chapter 5 speci?cations this chapter provides speci?cations for the E-110 core, including the ac timing and a pin summary. this chapter has three sections: section 5.1, derivation of ac timing and loading section 5.2, mac core ac timing section 5.3, mac core pin summary section 5.4, mac control module core ac timing section 5.5, mac control module core pin summary section 5.6, miim core ac timing section 5.7, miim core pin summary 5.1 derivation of ac timing and loading delay predictor software is included with every core lsi logic delivers for incorporation into an asic. the software generates an input loading report so you can plan for buffer strengths that drive core inputs. a ramp time violation report is generated when you integrate the core into the rest of your logic and run other simulation software. the report indicates if a core output is too heavily loaded. adjust buffering, wire length, and other parameters to eliminate the violation. there are no speci?c numbers in this chapter for ac timing and loading, because the numbers depend on the technology used and the design layout.
5-2 speci?cations 5.2 mac core ac timing this section provides a list of signals that must operate properly with respect to the mtxc, mrxc, and hclk signals. the relationship between the signals is depicted in figure 5.1. the numbers in figure 5.1 refer to the ac timing parameters listed in the ?rst column of table 5.1. the core has been veri?ed under worst- case process voltage and ambient temperature. figure 5.1 mac core setup, hold, and delay timing diagram 1, 3, 5, 7, 33, 35, 37 2, 4, 6, 8, 34, 36, 38 mtxc mrxc inputs valid outputs valid 9, 10, 11, 12, 13, 14, 39 29, 31 30, 32 inputs valid valid 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 40 outputs
mac core ac timing 5-3 table 5.1 mac core ac timing parameters parameter description parameter description 1. tpsf setup to mtxc 2. tpsf hold time after mtxc 3. tpef setup to mtxc 4. tpef hold time after mtxc 5. tpur setup to mtxc 6. tpur hold time after mtxc 7. tpd[7:0] setup to mtxc 8. tpd[7:0] hold time after mtxc 9. tpud delay from mtxc 10. tpdn delay from mtxc 11. tprt delay from mtxc 12. tpab delay from mtxc 13. tsvp_l delay from mtxc 14. tsv[30:0] delay from mtxc 15. rpd[7:0] delay from mrxc 16. rpdv delay from mrxc 17. rpsf delay from mrxc 18. rpef delay from mrxc 19. crco[9:1] delay from mrxc 20. crcg delay from mrxc 21. bco delay from mrxc 22. mco delay from mrxc 23. byte7 delay from mrxc 24. rsvp_l delay from mrxc 25. rsv[25:0] delay from mrxc 26. prsd[15:0] delay from mrxc 27. miilf delay from mrxc 28. nvalid delay from mrxc 29. mrxd[3:0] setup to mrxc 30. mrxd[3:0] hold time after mrxc 31. mrxdv setup to mrxc 32. mrxdv hold time after mrxc 33. tboff_sel setup before mtxc 34. tboff_sel hold after mtxc 35. bkoff_limit[1:0] setup before mtxc 36. bkoff_limit[1:0] hold after mtxc 37. fls_crs setup before mtxc 38. fls_crs hold after mtxc 39. trst_l delay from mtxc 40. rrst_l delay from mrxc
5-4 speci?cations 5.3 mac core pin summary table 5.2 summarizes the E-110 core input and output signals. the table provides the signal names and types for both outputs and inputs. table 5.2 mac core pin summary mnemonic description type active bco broadcast out output high bkoff_limit[1:0] backoff limit input byte7 byte 7 output high crcen crc append enable input high crcg crc good output high crco[9:1] crc out output fls_crs false carrier sense (backpressure control) input high fulld full-duplex control input high hrst_l host reset input low hugen huge packet enable input high hwd[10:0] host write data [10:0] input ipgr1[6:0] non back-to-back ipg (part 1) input ipgr2[6:0] non back-to back ipg (part 2) input ipgt[6:0] back-to-back ipg input lrng load random number generator input high mco multicast out output high mcol collision detected input high mcrs carrier sense input high mrxc receive nibble or symbol clock input high mrxd[3:0] receive nibble data input (sheet 1 of 3)
mac core pin summary 5-5 mrxdv receive data valid input high mrxer receive error input high mtxc transmit nibble or symbol clock input high mtxd[3:0] transmit nibble data output mtxen transmit enable output high mtxer transmit coding error output high nopre no preamble input high paden pad enable input high rpd[7:0] receive packet data output rpdv receive packet data valid output high rpef receive packet end of frame output high rpsf receive packet start of frame output high rrst_l receive reset output low rstat request mii status input high rsv[25:0] receive statistics vector output high rsvp_l receive statistics vector pulse output low rtryl retry late collision input high scan status read scan input high tboff_sel stop backoff input high test_se scan enable input high test_si scan input input test_so scan output output tmode test mode input high tpab transmit packet abort output high table 5.2 mac core pin summary (cont.) mnemonic description type active (sheet 2 of 3)
5-6 speci?cations 5.4 mac control module core ac timing this section gives a list of the signals that must operate properly with respect to the mtxc and mrxc signals. the relationship between the signals is depicted in figure 5.2. the numbers in figure 5.2 refer to the ac timing parameters listed in the ?rst column of table 5.3. the mac control module core has been veri?ed under worst-case process, voltage, and ambient temperature. tpd[7:0] transmit packet data input tpdn transmit packet done output high tpef transmit packet end of frame input high tprt transmit packet retry output high tpsf transmit packet start of frame input high tpud transmit packet data used output high tpur transmit packet data underrun input high trst_l transmit reset output low tsv[30:0] transmit statistics vector output tsvp_l transmit statistics vector pulse output low table 5.2 mac core pin summary (cont.) mnemonic description type active (sheet 3 of 3)
mac control module core ac timing 5-7 figure 5.2 mac control module setup, hold, and delay timing diagram 3, 5, 7, 21, 23, 26 4, 6, 8, 22, 24, 27 mtxc mrxc inputs valid outputs valid 25 1, 11, 13, 15, 17, 19 2, 12, 14, 16, 18, 20 inputs valid valid 9, 10 outputs table 5.3 mac control module ac timing parameters parameter description parameter description 1. addr_match setup to mrxc 2. addr_match hold time after mrxc 3. ctlp setup to mtxc 4. ctlp hold time after mtxc 5. flowcon_en setup to mtxc 6. flowcon_en hold time after mtxc 7. hst_tpsf setup to mtxc 8. hst_tpsf hold time after mtxc 9. pause_active delay from mrxc 10. rcvng_pause_frame delay from mrxc 11. rpd[7:0] setup to mrxc 12. rpd[7:0] hold time after mrxc 13. rpdv setup to mrxc 14. rpdv hold time after mrxc 15. rpef setup to mrxc 16. rpef hold time after mrxc 17. rpsf setup to mrxc 18. rpsf hold time after mrxc 19. rrst_l setup to mrxc 20. rrst_l hold time after mrxc (sheet 1 of 2)
5-8 speci?cations 5.5 mac control module core pin summary table 5.4 summarizes the mac control module core signals. 21. tpab setup to mtxc 22. tpab hold time after mtxc 23. tpdn setup to mtxc 24. tpdn hold time after mtxc 25. tpsf delay after mtxc 26. trst_l setup to mtxc 27. trst_l hold time after mtxc table 5.3 mac control module ac timing parameters (cont.) parameter description parameter description (sheet 2 of 2) table 5.4 mac control module pin summary mnemonic description type active addr_match unicast address match input high ctlp host control packet transmit request input high flowcon_en flow control enable input high hst_tpsf host packet transmit request input high mrxc receive nibble or symbol clock input mtxc transmit nibble or symbol clock input pause_active pause in progress output high pause_mirror[23:0] pause mirror counter value output pause_rsvp_l comprehensive receive statistics vector pulse output low pause_time_in[15:0] transmitted pause time input rcv_load_dly[3:0] receiver delay in loading transmitted pause input rcvng_pause_frame receiving pause frame output high rpd[7:0] receive packet data input (sheet 1 of 2)
mac control module core pin summary 5-9 rpdv receive packet data valid input high rsv_good received statistics vector good input high rsvd_pausef received pause frame output high rpef receive packet end of frame input high rpsf receive packet start of frame output high rrst_l receive reset input low tpab transmit packet abort input high tpdn transmit packet done input high tpsf transmit packet start of frame output high trst_l transmit reset input low xmt_pausef transmitted pause frame output high unsupp_opcode unsupported opcode output high table 5.4 mac control module pin summary (cont.) mnemonic description type active (sheet 2 of 2)
5-10 speci?cations 5.6 miim core ac timing this section gives a list of the signals that must operate properly with respect to the hclk signal. the relationship between the signals is depicted in figure 5.3. the numbers in figure 5.3 refer to the ac timing parameters listed in the ?rst column of table 5.5. the miim core has been veri?ed under worst-case process, voltage, and ambient temperature. figure 5.3 miim core setup, hold, and delay timing diagram table 5.5 miim core ac timing parameters parameter description parameter description 1. busy delay from hclk 2. ctld[15:0] setup to hclk 3. ctld[15:0] hold time after hclk 4. fiad[4:0] setup to hclk 5. fiad[4:0] hold time after hclk 6. rgad[4:0] setup to hclk 7. rgad[4:0] hold time after hclk 8. lctld setup to hclk 9. lctld hold time after hclk 10. rstat setup to hclk 11. rstat hold time after hclk 12. scan setup to hclk 13. scan hold time after hclk 2, 4, 6, 8, 10, 12 3, 5, 7, 9, 11, 13 hclk inputs valid valid 1
miim core pin summary 5-11 5.7 miim core pin summary table 5.6 summarizes the miim core input and output signals. the table provides the signal names and types for both outputs and inputs. table 5.6 miim core pin summary mnemonic description type active busy busy output high clks clock select input high ctld[15:0] control data input fiad[4:0] phy address[4:0] input hclk host clock input high hrst_l host reset input low lctld load control data input high mdc miim data clock output high mdi miim data in input mdo miim data out output mdoen miim data 3-state enable output high miilf mii link failure output high nvalid invalid output high prsd[15:0] phy read status data output rgad[4:0] register address[4:0] input rstat request mii status input high scan status read scan input high
5-12 speci?cations
a-1 appendix a glossary address filtering (individual, multicast, promiscuous) address ?ltering is the process the E-110 core performs to match a des- tination address within a received frame with an address derived at the receiving station. there are three common types of address ?ltering: individualthe ?rst bit of an individual address is a zero. the incom- ing destination address is compared with the data from the individual address pins. when all 48 bits match and the receiver is enabled, the address ?lter passes. multicastthe ?rst bit of an multicast address is a one. when the destination address bits that are received in the frame contain a mul- ticast address, the E-110 core uses its built-in fcs generator to com- pute a nine-bit polynomial (the nine most signi?cant bits of the 32-bit fcs generator) from the incoming address. the value of this poly- nomial can be used as an index into an external multicast ?lter hash table. external logic can decide to either accept or reject the incom- ing frame. the external logic enables the multicast address ?lter. promiscuouswhen the external logic asserts the individual address promiscuous mode enable pin (rpmen) high and the destination address is an individual address, the address ?lter always passes, and the incoming frame is received. attachment unit interface (aui) the aui is the interface between the medium attachment unit (mau) and the data terminal equipment (dte) device or repeater. a typical aui interface consists of a 15-pin d connector.
a-2 glossary backoff in ieee 802.3 networks, backoff occurs when two or more nodes attempt a transmission and collide. the function of stopping transmission and waiting a speci?ed random time before retrying the transmission is con- sidered backoff. in ieee 802.3 networks a truncated binary exponential backoff algorithm is employed. broadcast packet a broadcast packet has the destination address ?eld set to all ones, which indicates it is being sent to all destinations on the network. bridge a bridge connects distinct segments of an ethernet lan (usually refer- ring to a physical length of wire) and transmit traf?c between them. a bridge allows you to extend the maximum size of the network while still not exceeding the maximum wire length, attached device count, or num- ber of repeaters for a network segment. collision when an ethernet station is operating in the aui mode, it can sense a change in the energy level of the communication channel and interpret the phenomenon as a collision. a collision is caused by two stations attempting to transmit at the same time. collision detection collision detection is the ability of a transmitting node on an ethernet lan to sense a change in the energy level of the channel and to interpret the phenomenon as a collision. csma/cd (carrier sense multiple access with collision detection) a lan protocol access method where the nodes are attached to a cable. when a node transmits data onto the network and raises the carrier, the remaining nodes detect the carrier (carrier sense) and listen for the information to detect if it is intended for them. the nodes have network access (multiple access) and can send if no other transmission is taking place. if two nodes attempt to send simultaneously, a collision takes place (collision detection) and both nodes must retry at random intervals.
glossary a-3 deference deference (or deferral length) is the time the mac transmit function waits for the network to be free before it can transmit. see also excess deferral . dribble nibble a nibble that is extra and occurs when, at the end of a frame, less than a complete byte is received. it is possible to have one dribble nibble at the end of a frame if a complete byte is not received. end of frame delimiter three consecutive ones at the end of a frame that are not manchester- encoded; that is, they are non-return-to-zero bits that do not contain a tran- sition in the middle of the bit time. the purpose of the end of frame delimiter is to cause the phase-lock loop at the receiving station to lose lock so the host can be noti?ed that the frame has ended. when a receiving node detects a bit that is not manchester-encoded, it considers the previous four bytes to be the fcs. ethernet lan a branching broadcast communications system for carrying digital data packets among locally distributed computing stations. ethernet is a 10-mbit/s baseband, local area network that has evolved into the ieee 802.3 speci?cation and is de?ned by a data-link protocol that spec- i?es how data is placed on and retrieved from a common transmission medium. ethernet is used as the underlying transport vehicle by several upper level protocols, including tcp/ip and xerox network system (xns). see ieee 802.3/ieee 802.3u . excess deferral the time period when the media is busy longer than twice the maximum frame size. when hugen is deasserted, the maximum frame size is 1518 bytes, so excess deferral in this case is: 1518 bytes x 8 bits/byte x 2 = 24,288 bits (242.88 m s at 100 mbit/s or 2.4288 ms at 10 mbit/s)
a-4 glossary when hugen is asserted, the maximum frame size is 32 kbytes, so excess deferral in this case is: 32 kbytes x 8 bits/byte x 2 = 524,288 bits (5242.88 m s at 100 mbit/s or 52.43 ms at 10 mbit/s) fast ethernet compared to the 10-mbit/s speci?cations, the 100-mbit/s fast ethernet system results in a factor of ten reduction in the bit time, which is the amount of time it takes to transmit a bit on the ethernet channel. the result is a tenfold increase in the speed of the packets over the media system. however, the other important aspects of the ethernet system, including the frame format, the amount of data a frame may carry, and the media access control mechanism, are all unchanged. the fast ethernet speci?cations include mechanisms for auto-negotia- tion of the media speed. this makes it possible for vendors to provide dual-speed ethernet interfaces that can be installed and run at either 10 mbit/s or 100 mbit/s automatically. there are three media varieties that have been speci?ed for transmitting 100-mbit/s ethernet signals: 100base-tx 100base-fx 100base-t4 the identi?ers include three pieces of information. the ?rst item, 100, stands for the media speed of 100 mbit/s. base stands for baseband, which is a type of signaling. baseband signaling simply means that ethernet signals are the only signals carried over the media system. the third part of the identi?er provides an indication of the segment type. the t4 segment type is a twisted-pair segment that uses four pairs of telephone-grade twisted-pair wire. the tx segment type is a twisted- pair segment that uses two pairs of wires and is based on the data grade twisted-pair physical medium standard developed by ansi. the fx segment type is a ?ber optic link segment based on the ?ber optic physical medium standard developed by ansi and that uses two strands of ?ber cable. the tx and fx medium standards are collectively known as 100base-x.
glossary a-5 the 100base-tx and 100base-fx media standards used in fast ethernet are both adopted from physical media standards ?rst developed by ansi, the american national standards institute. the ansi physical media standards were originally developed for the fiber distributed data interface (fddi) lan standard (ansi standard x3t9.5), and are widely used in fddi lans. rather than reinventing the wheel when it came to signaling at 100 mbit/s, the fast ethernet standard adapted these two ansi media standards for use in the new fast ethernet medium speci?cations. the t4 standard was also provided to make it possible to use lower-quality twisted-pair wire for 100-mbit/s ethernet signals. frame an ethernet frame contains the following eight ?elds: preamble start of frame delimiter destination address source address length data pad (if necessary) frame check sequence frame check sequence (fcs) the ethernet transmit and receive algorithm uses the standard ieee 802.3 four-byte fcs ?eld to ensure data integrity. during data transmis- sion, the E-110 core uses a 32-bit linear feedback shift register (lfsr) to compute the value that will be sent in the fcs ?eld. the fcs value is a function of the content of the source address, destination address, length, data, and pad ?elds. on data reception, the E-110 core preloads the lfsr with all ones and updates this value with each byte received, including the received fcs. if the ?nal value in the lfsr does not match a predetermined value after all bytes including the fcs are received, the E-110 core ?ags an fcs error.
a-6 glossary hub the E-110 core operating in 10base-t mode uses a hub to concentrate connections to multiple terminals. hubs come in various sizes, with 4-port, 8-port, and 12-port being the most common. the number of ports indicates the number of terminals that can be connected to the hub. most hubs have built-in transceivers and network management features. hubs are mainly used in star topology lans. the E-110 core is speci?cally designed for multiple-core integration, especially for hub-on-a-chip implementations. ieee 802.3/ieee 802.3u ieee 802.3 is a standard set by the ieee for csma/cd 10 mbit/s net- work protocol, which is a physical layer de?nition including speci?cations for cabling in addition to transmitting data and controlling cable access. ieee 802.3u is an ieee standard that describes the mac, physical layer, mau, and repeater for 100-mbit/s 100base-t operation, and is a supplement to the ieee 802.3 speci?cation. see ethernet lan . invalid preamble an invalid preamble has a content that is not 0x55 or contains the code 0x50555 in the last reception. jabber a condition on an ethernet network when a node transmits for longer than the speci?ed time. jam in ieee 802.3 networks, when a collision occurs, the colliding nodes ensure that the collision is seen by the entire network by continuing to transmit for a minimum time during a collision. this occurrence is known as jamming. link failure in the twisted-pair mode, a link failure can be caused by a twisted-pair transceiver failure or by a broken twisted-pair receive cable. a link failure occurs when there are eight consecutive missing link integrity pulses.
glossary a-7 local area network (lan) a communications system linking computers together to form a network whose dimensions typically are less than ?ve kilometers. transmissions within a local area network generally are digital, carrying data among stations at rates usually above 1 mbit/s. a lan is an assembly of computing resources such as microcomputers (for example, pcs), printers, minicomputers and mainframes linked by a common transmission medium, including coaxial cable or twisted-pair wiring. long event a long event occurs if the mcrs signal is asserted for over 50,000 bit times if the hugen signal is not asserted and over 200,000 bit times if hugen is asserted. a long event is not detected in full duplex mode. mii management frame format the mii management frame format is used to write control information to the phy and read status information from the phy. it is described in detail in ieee 802.3u, clause 22.2.4.4 minimally quali?ed receive event an event occurring when the mac receives at least one nibble of data beyond a valid preamble and sfd. packet data sent in the data ?eld of an ethernet frame. packet receive attempt a packet receive attempt occurs when the mac sees a valid preamble and a valid sfd. when the mac sees these two events, it tries to receive a packet. errors in the packet after the preamble and sfd may, however, cause the packet to be discarded. start of frame delimiter (sfd) the eight-bit sfd ?eld follows the seven-octet preamble at the beginning of a frame and contains the 0b10101011 bit pattern. this pattern allows synchronization of the data received in the rest of the frame.
a-8 glossary switch synonymous with bridge . transceiver a combined transmitter and receiver and is an essential element of all lan networks. when an ethernet lan operates in the 10base-t mode with an miim interface to a phy, a transceiver is generally used to send the mdo and mdi mac signals over a single signal, mdio, to the phy. the mac mdoen signal controls the direction of data transfer through the transceiver. twisted-pair twisted-pair wire is a cable comprised of two 18- to 24-awg (american wire gauge) solid copper strands twisted around each other. the twisting provides a measure of protection from electromagnetic and radio-frequency interference (emi/rfi). two types are available: shielded and unshielded. the former is wrapped inside a metallic sheath that provides protection from emi/rfi. the latter, also known as telephone wire, is covered with plastic or pvc, which provides no protection from emi/rfi. in 10base-t terminology, a twisted-pair transmission system refers to the twisted-pair wire link and its two attached maus. under?ow an under?ow, or underrun, condition occurs when the host does not supply new transmit packet bytes fast enough to keep up with the mac transmit requirements during a packet transmission.
customer feedback we would appreciate your feedback on this document. please copy the following page, add your comments, and fax it to us at the number shown. if appropriate, please also fax copies of any marked-up pages from this document. impor tant: please include your name, phone number, fax number, and company address so that we may contact you directly for clari?cation or additional information. thank you for your help in improving the quality of our documents.
customer feedback readers comments fax your comments to: lsi logic corporation technical publications m/s e-198 fax: 408.433.4333 please tell us how you rate this document: E-110 core technical manual. place a check mark in the appropriate blank for each category. what could we do to improve this document? if you found errors in this document, please specify the error and page number. if appropriate, please fax a marked-up copy of the page(s). please complete the information below so that we may contact you directly for clari?cation or additional information. excellent good average fair poor completeness of information ____ ____ ____ ____ ____ clarity of information ____ ____ ____ ____ ____ ease of ?nding information ____ ____ ____ ____ ____ technical content ____ ____ ____ ____ ____ usefulness of examples and illustrations ____ ____ ____ ____ ____ overall manual ____ ____ ____ ____ ____ name date telephone title company name street city, state, zip department mail stop fax
u.s. distributors by state a. e. avnet electronics w. e. wyle electronics alabama huntsville a. e. tel: 205.837.8700 w. e. tel: 800.964.9953 alaska a. e. tel: 800.332.8638 arizona phoenix a. e. tel: 602.736.7000 w. e. tel: 800.528.4040 tucson a. e. tel: 520.742.0515 california irvine a. e. tel: 949.789.4100 w. e. tel: 800.626.9953 los angeles a. e. tel: 818.594.0404 w. e. tel: 800.288.9953 sacramento a. e. tel: 916.632.4500 w. e. tel: 800.627.9953 san diego a. e. tel: 619.571.7540 w. e. tel: 800.829.9953 san jose a. e. tel: 408.435.3500 santa clara w. e. tel: 800.866.9953 woodland hills a. e. tel: 818.594.0404 colorado denver a. e. tel: 303.790.1662 w. e. tel: 800.933.9953 connecticut chesire a. e. tel: 203.271.5700 wallingford w. e. tel: 800.605.9953 delaware north/south a. e. tel: 800.526.4812 tel: 800.638.5988 florida fort lauderdale a. e. tel: 305.484.5482 w. e. tel: 800.568.9953 orlando a. e. tel: 407.657.3300 w. e. tel: 407.740.7450 tampa w. e. tel: 800.395.9953 st. petersburg a. e. tel: 813.507.5000 georgia atlanta a. e. tel: 770.623.4400 w. e. tel: 800.876.9953 hawaii a. e. tel: 800.851.2282 idaho a. e. tel: 801.266.2022 illinois north/south a. e. tel: 847.797.7300 tel: 314.291.5350 chicago w. e. tel: 800.853.9953 indiana indianapolis a. e. tel: 317.575.3500 w. e. tel: 888.358.9953 iowa cedar rapids a. e. tel: 319.393.0033 kansas kansas city a. e. tel: 913.663.7900 kentucky central/northern/ western a. e. tel: 800.984.9503 tel: 800.767.0329 tel: 800.829.0146 louisiana north/south a. e. tel: 800.231.0253 tel: 800.231.5575 maine a. e. tel: 800.272.9255 maryland baltimore a. e. tel: 410.720.3400 w. e. tel: 800.863.9953 massachusetts boston a. e. tel: 978.532.9808 w. e. tel: 800.444.9953 michigan detroit a. e. tel: 313.416.5800 w. e. tel: 888.318.9953 grandville a. e. tel: 616.531.0345 minnesota minneapolis a. e. tel: 612.881.2600 w. e. tel: 800.860.9953 mississippi a. e. tel: 800.633.2918 missouri st. louis a. e. tel: 314.291.5350 montana a. e. tel: 800.526.1741 nebraska a. e. tel: 800.332.4375 nevada las vegas a. e. tel: 800.528.8471 w. e. tel: 702.765.7117 new hampshire a. e. tel: 800.272.9255 new jersey north/south a. e. tel: 201.515.1641 tel: 609.222.6400 oradell w. e. tel: 201.261.3200 pine brook w. e. tel: 800.862.9953 new mexico albuquerque a. e. tel: 505.293.5119 new york long island a. e. tel: 516.434.7400 w. e. tel: 800.861.9953 rochester a. e. tel: 716.475.9130 w. e. tel: 800.319.9953 syracuse a. e. tel: 315.453.4000 north carolina raleigh a. e. tel: 919.872.0712 w. e. tel: 800.560.9953 north dakota a. e. tel: 800.829.0116 ohio cleveland a. e. tel: 216.498.1100 w. e. tel: 800.763.9953 dayton a. e. tel: 614.888.3313 w. e. tel: 800.763.9953 oklahoma tulsa a. e. tel: 918.459.6000 oregon portland a. e. tel: 503.526.6200 w. e. tel: 800.879.9953 pennsylvania pittsburgh a. e. tel: 412.281.4150 philadelphia a. e. tel: 800.526.4812 w. e. tel: 800.871.9953 rhode island a. e. 800.272.9255 south carolina a. e. tel: 919.872.0712 south dakota a. e. tel: 800.829.0116 tennessee east/west a. e. tel: 800.241.8182 tel: 800.633.2918 texas austin a. e. tel: 512.219.3700 w. e. tel: 800.365.9953 dallas a. e. tel: 214.553.4300 w. e. tel: 800.955.9953 el paso a. e. tel: 800.526.9238 houston a. e. tel: 713.781.6100 w. e. tel: 800.888.9953 rio grande valley a. e. tel: 210.412.2047 utah draper w. e. tel: 800.414.4144 salt lake city a. e. tel: 801.365.3800 w. e. tel: 800.477.9953 vermont a. e. tel: 800.272.9255 virginia a. e. tel: 800.638.5988 washington seattle a. e. tel: 206.882.7000 w. e. tel: 800.248.9953 west virginia a. e. tel: 800.638.5988 wisconsin milwaukee a. e. tel: 414.513.1500 w. e. tel: 800.867.9953 wyoming a. e. tel: 800.332.9326
sales of?ces and design resource centers lsi logic corporation corporate headquarters tel: 408.433.8000 fax: 408.433.8989 north america california irvine tel: 949.553.5600 fax: 949.474.8101 pleasanton design center tel: 925.730.8800 fax: 925.730.8700 san diego tel: 619.613.8300 fax: 619.613.8350 wireless design center tel: 619.350.5560 fax: 619.350.0171 silicon valley tel: 408.433.8000 fax: 408.954.3353 colorado boulder tel: 303.447.3800 fax: 303.541.0641 florida boca raton tel: 561.989.3236 fax: 561.989.3237 georgia roswell tel: 770.641.8001 fax: 770.641.8005 illinois schaumburg tel: 847.995.1600 fax: 847.995.1622 kentucky bowling green tel: 502.793.0010 fax: 502.793.0040 maryland bethesda tel: 301.897.5800 fax: 301.897.8389 massachusetts waltham tel: 781.890.0180 fax: 781.890.6158 minnesota minneapolis tel: 612.921.8300 fax: 612.921.8399 new jersey edison tel: 732.549.4500 fax: 732.549.4802 new york fairport tel: 716.218.0020 fax: 716.218.9010 north carolina raleigh tel: 919.785.4520 fax: 919.783.8909 oregon beaverton tel: 503.645.0589 fax: 503.645.6612 texas austin tel: 512.388.7294 fax: 512.388.4171 dallas tel: 972.503.3205 fax: 972.503.2258 tel: 972.244.5000 fax: 972.244.5001 houston tel: 281.379.7800 fax: 281.379.7818 washington issaquah tel: 425.837.1733 fax: 425.837.1734 canada ontario ottawa tel: 613.592.1263 fax: 613.592.3253 toronto tel: 416.620.7400 fax: 416.620.5005 quebec montreal tel: 514.694.2417 fax: 514.694.2699 international australia new south wales reptechnic pty ltd tel: 612.9953.9844 fax: 612.9953.9683 china beijing lsi logic international services inc tel: 86.10.6804.2534 fax: 86.10.6804.2521 france paris lsi logic s.a. immeuble europa tel: 33.1.34.63.13.13 fax: 33.1.34.63.13.19 germany munich lsi logic gmbh tel: 49.89.4.58.33.0 fax: 49.89.4.58.33.108 stuttgart tel: 49.711.13.96.90 fax: 49.711.86.61.428 hong kong hong kong avt industrial ltd tel: 852.2428.0008 fax: 852.2401.2105 india bangalore spike technologies india private ltd tel: 91.80.664.5530 fax: 91.80.664.9748 israel ramat hasharon lsi logic tel: 972.3.5.480480 fax: 972.3.5.403747 netanya vlsi development centre tel: 972.9.657190 fax: 972.9.657194 italy milano lsi logic s.p.a. tel: 39.039.687371 fax: 39.039.6057867 japan tokyo lsi logic k.k. tel: 81.3.5463.7821 fax: 81.3.5463.7820 osaka tel: 81.6.947.5281 fax: 81.6.947.5287 korea seoul lsi logic corporation of korea ltd tel: 82.2.528.3400 fax: 82.2.528.2250 the netherlands eindhoven lsi logic europe ltd tel: 31.40.265.3580 fax: 31.40.296.2109 singapore singapore lsi logic pte ltd tel: 65.334.9061 fax: 65.334.4749 tel: 65.835.5040 fax: 65.732.5047 sweden stockholm lsi logic ab tel: 46.8.444.15.00 fax: 46.8.750.66.47 switzerland brugg/biel lsi logic sulzer ag tel: 41.32.536363 fax: 41.32.536367 taiwan taipei lsi logic asia-paci?c tel: 886.2.2718.7828 fax: 886.2.2718.8869 avnet-mercuries corporation, ltd tel: 886.2.2503.1111 fax: 886.2.2503.1449 jeilin technology corporation, ltd tel: 886.2.2248.4828 fax: 886.2.2242.4397 lumax international corporation, ltd tel: 886.2.2788.3656 fax: 886.2.2788.3568 prospect technology corporation, ltd tel: 886.2.2721.9533 fax: 886.2.2773.3756 united kingdom bracknell lsi logic europe ltd tel: 44.1344.426544 fax: 44.1344.481039 sales of?ces with design resource centers

▲Up To Search▲

Price & Availability of E-110

	To Download E-110 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .